From nobody Wed Oct 1 01:38:51 2014 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 2A19A1A9175 for ; Wed, 1 Oct 2014 01:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 UmAt0QivamZI for ; Wed, 1 Oct 2014 01:38:47 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C611A9173 for ; Wed, 1 Oct 2014 01:38:46 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s918ciYR022614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Oct 2014 08:38:44 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s918ccqa030378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Oct 2014 10:38:43 +0200 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Oct 2014 10:38:39 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.218]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0195.001; Wed, 1 Oct 2014 10:38:39 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC #70 - Proposed resolution to core issue Thread-Index: AQHP3LzxVwlySCWp3U+Xg2cvYp/Vlpwa49oA Date: Wed, 1 Oct 2014 08:38:39 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681521304D@DEMUMBX014.nsn-intra.net> References: <542AC192.9090600@usdonovans.com> In-Reply-To: <542AC192.9090600@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.109] Content-Type: multipart/mixed; boundary="_002_5BCBA1FC2B7F0B4C9D935572D90006681521304DDEMUMBX014nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 26464 X-purgate-ID: 151667::1412152724-00001FC1-2BC4EB59/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/E313JdFRibiD0vRZr6Otv7Jjr9Y Subject: Re: [Dime] DOIC #70 - Proposed resolution to core issue 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, 01 Oct 2014 08:38:49 -0000 --_002_5BCBA1FC2B7F0B4C9D935572D90006681521304DDEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, I agree that there may be cases where the agent that selects the server doe= s not support DOIC, and consequently transparently forwards a host-type OLR= to the client which then receives a host-type OLR in response to a realm-t= ype request. The example flow in Appendix B, however, assumes that the agent supports DO= IC. Please find the proposed modification attached. Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Tuesday, September 30, 2014 4:44 PM To: dime@ietf.org Subject: [Dime] DOIC #70 - Proposed resolution to core issue All, The core issue raised in issue #70 is whether a client can receive an=20 OLR of type host when the request sent by the client was realm routed. I do not support the suggested change as there are scenarios where=20 clients MUST be prepared to receive the OLR of type host when the client=20 does not do server selection. This is required for the scenario where=20 agents do not support DOIC. If the request does not contain a=20 Destination-Host AVP then agents will be responsible for server=20 selection. An overloaded server will send an OLR of type host that=20 will find its way back to the client. It is true that this might cause unneeded OCS entries in the client in a=20 scenario where the client will never do server selection for that=20 overloaded server. This concern can be addressed by making it up to=20 local policy whether or not the client saves OCS for the overload=20 report. If the client knows that it will never do server selection for=20 a server indicated in a host OLR then the client can choose to not save=20 the overload report. Based on this, I propose that we close issue #70 without changes to the=20 DOIC specification. The discussion about the handling of a mix of overload abatement=20 algorithms should continue. We can open a separate issue if needed to=20 address that functionality. Regards, Steve _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_002_5BCBA1FC2B7F0B4C9D935572D90006681521304DDEMUMBX014nsnin_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="#70rev1.docx" Content-Description: #70rev1.docx Content-Disposition: attachment; filename="#70rev1.docx"; size=17290; creation-date="Wed, 01 Oct 2014 08:05:32 GMT"; modification-date="Wed, 01 Oct 2014 08:30:29 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDr01KodAEAAKMFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lMtOwzAQRfdI/IPlLUrcskAIJemCxxIqUT7AtSethV+y3dffM0nbCAFNRatuIkXxnHvveCbFaG00 WUKIytmSDvMBJWCFk8rOSvoxecnuKYmJW8m1s1DSDUQ6qq6visnGQyRYbWNJ5yn5B8aimIPhMXce LH6pXTA84WuYMc/FJ58Bux0M7phwNoFNWWoYtCre0EBQEsiYh/TKDeqwlQsSDxqDB2OONEoet2WN ckm591oJntA3W1r5QzNzda0ESCcWDSBvaD44ATFiMqPzPfmmIbOqeIKaL3Qiz2t0tm1GAB3/J7oL mWNlayzOlY89Cv2pds4ONqcL1485oTkd2XBl9/4P+ohpo+ECV7Tl9smjz3FwPjIchrNHBJqblyAz nBMPISnoru5wdEgJ5+kS4XfkvvjtiiRcOWDtc3h2D1rMUcka93DCpxrO1vu1lh36qIkVTN8v1v1v 8D4j3fwJF05oxv530VT/MXWs/cVWXwAAAP//AwBQSwMEFAAGAAgAAAAhAB6RGrfzAAAATgIAAAsA CAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMkttKA0EMhu8F32HIfTfbCiLS2d5IoXci6wOEmewBdw7MpNq+ vaMgulDbXub058tP1puDm9Q7pzwGr2FZ1aDYm2BH32t4bbeLB1BZyFuagmcNR86waW5v1i88kZSh PIwxq6Lis4ZBJD4iZjOwo1yFyL5UupAcSQlTj5HMG/WMq7q+x/RXA5qZptpZDWln70C1x1g2X9YO XTcafgpm79jLiRXIB2Fv2S5iKmxJxnKNain1LBpsMM8lnZFirAo24Gmi1fVE/1+LjoUsCaEJic/z fHWcA1peD3TZonnHrzsfIVksFn17+0ODsy9oPgEAAP//AwBQSwMEFAAGAAgAAAAhAJs7tcMJAQAA tAMAABwACAF3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAArJNNTsMwEIX3SNzBmj1xUqBCVZ1uUKVuIRzAdSY/IrEjzxTI7TGRUlJR hU02luZZfu+zZ7zdfbWN+EBPtbMKkigGgda4vLalgrdsf/cEgljbXDfOooIeCXbp7c32BRvN4RBV dUciuFhSUDF3GynJVNhqilyHNuwUzreaQ+lL2WnzrkuUqzheSz/1gPTCUxxyBf6Q34PI+i4k/+/t iqI2+OzMqUXLVyLkJx5fkTlcjoKt9iWygokYBVqQ10FWS4LQH4pRmUNIFkXgvgnNPD8DDfVc/HrJ eA4jgr/pQymHNZljeFySoXCWM31sJhxnaQ7iYUkI49qfcZ10YlRGBHnx19JvAAAA//8DAFBLAwQU AAYACAAAACEA/QH3PcgSAABhywAAEQAAAHdvcmQvZG9jdW1lbnQueG1s7F3tb6M4Hv5+0v0PVk7a y0hNG5Im7WS3WXUmMzcr3WmrtHsn3TcHnAYNAQ5IM5X2j7/H5s0kkAANnbLr+TChkIB5/PPze7X9 08/f1hZ5Yp5vOvZNRzvvdwizdccw7cebzm8Pn3vXHeIH1Dao5djspvPM/M7P07/+5aftxHD0zZrZ AcEtbH/yhKurIHAnFxe+vmJr6p87LrNxcel4axrgT+/xYk29rxu3pztrlwbmwrTM4Pli0O+PO9Ft nJvOxrMn0S16a1P3HN9ZBvwnE2e5NHUWfcS/8Mo8N/zlLGqyeOKFxyy0wbH9len68d3Wde+GV1zF N3k69BJPayv+3tYt8zTDo1v0x9oKm711PMP1HJ35Ps7OwovJHbX+oWdHAPJbJL8o04TsM+OWrKlp J7fh0rHT/0nnnaPzLsJnX/BbpS8CLKaQpYVjPPNPl2wnkEVjftPp96/fDz7cXnbiU3fo6L2TM7ak GyvYv3InnRJ3vvPEx33wbDHc8olaN507C2/wwL4FnQt+0Qu/Y1H7Mf4Gs3u/3fOrF9FlfLrh17zc hpW9z3YSTP921Z+QWxejxDC/kQ+kRz59o2vXYvxpQfhM8b8rmh4/T3qz+NTbwoZj1K4Wo3NzoazQ m5y/Jr5LdYwD12M+855YZ0p+sUmwYoSFHUtMW7c2BjNwIPX8GTEDYvpEBxmZBvNwPVjRQPzy9hEc 23KBaA5ej7mOF/jki+MHxIEisxxqEMP0mB5Yz2RB9a8kcASQHy0TSJ6R7YqFfRKeIB7734b5CmKh yHMkeEt9AhUuMJwzaq0BoRmsnE2wIjMAZ9pCi4Zd0MUXQ/S5MNvoBSjYd+dKfgvoIQPMdgI9yU2q OTQQuw+oF4CVTAOEHymol5LU9BdiOMR2AkIfPcYIXaAb0bPgngVb0SfT2XgHmvTJNnYaJBGkl1Gt H6M3YUvQma2z6AU+OzZG63ZCfd00H2Amgi3Xpu14X25BfVzXr/jB/hWhoHc08z8+yJo5RS9+ptxW rr9FY3FSWBgZlSm9xs4zstqfq2UlzEVMIVQVyMGyCAzUJ2iyHV7OMDFxbDB0wsYRDRPQTUYClTGR GhM+d7cAIlwx4rtMN+EOkRVUX9tlUnVy2smRD0D8FcVAWjCyhju+NJmhOnnX/WuBk1eg9+88x3V8 2Plh5+rChJq0nPjaN4rb1+LmXCkS/YvcIv5XqNDF+XstukzuB8nRsOUC2zyYgOr3GK5jRwrMArJM AASYXe0dmYceO+lmEEvt/13vSTuV9zSbTzzuAR94buoixU+VfIs36yKJtoIMT+QivYt6TBL9DGSK dlNzTxbuXvTvh8fgRwm75CvSOYVnCbLIAy7vnAJTgck56USJnUpghjaWzyzESn0izKyXD/NPt+Or 2SxJnb1algwa5M77uOIKOAq+DXgjKGLFDtJ3v1meqa/If0y2Yvy8QQPE/wZ97bKn9Xt97UHrT/ra pN//r8gK4l5J5i286ZSPVJGme9XuyvCDZDTyTFx/OJ6NtQTqMKwYnZRUf25YcR+uYUNw8cClJFZ5 JJiey7xueV1dLHRZjE7tte+jKJLGryl0tft71Fx/V2KhtPPzjlovECgveV0Wqi0QVw21FASgBCJV SyhraolAvG+opVUFojuo4Xjn5y1rDw5N6NkGiJ2rx2rO/e6bSUU5ktZ/uw6/aD83pkRrMRikpGj9 /mnK2uP9kwQVWq+NtKasvEKjuH6PNmVKVaWfo6GR9ktFU7ZgA1LRlD1VVSryjNX0XPtFoilrsAGR aMqiUiKRiadoTdmDpxeJASYTNGJk1xcJhNfiIlFmnKH0M8BkA5/8+s9567li0JRt3IBgNGgmKic3 dXIH7bEzB2/Fzkyth7yj9rNEe4zMgTIyMRmk+WD5oD1G5uCtGJnd4TuCOvUt80j31y+Te+0MJsRk /nAz+/KuJkfszHaTUnaR8x7FaE4tEFDvhxNqtWMHg6ZM1VL2X6Yb8I5xiEsK1MWnak8FkDJqP1jB j3GMQjqdKpFMe7hNxQNvf6r5jsdNswxGxfVcw93g6yk68MCz05qu5MltiPGGjeXjOyfGG9GN9B65 GeqYHY4POSX0nb3JwsdRAz/kApfyRnqUkVDFIPkldClcPmPCsz/zMMcNhzbmeZPZnAQe5csI8Hk0 94MfMN/6x3tVx/wGksPFBlD2yqsbQCenSj7ou6Pq6dRhXFL8YsOlUq4zeaykLN5sYjNs7MmUXpp1 TIlF8fBxS+732BZWpcww819oWnG+SMXv8JESzhLCeRjC9KoCsxKYO6XMfJ6YJLcKzEpgplKYd6TA VGByF/B7zFjIk8f0nJLMSpLZHdfwAwbfZULjMH5sK/wA0dgG/AAl35XkO/YD0s8dj0DhWQnPlGjz jhSYCsy3ZBZgrQgsLZaWXJ2ft30RGymTWDfrpET0LYloSqOKPJVkfi/J7F5lC0oGZ7woNaoo+V1J ZiXJlGsxUrtThaK4NxQGDFS6jw8pFT2JEHAzS7d+11XRLeoHcyyIzhfBvqOP7AMWXPoqFn+tJrNx LDqqAUCpP9Ztwsq3W8kaVbRaiVZTSynvSIGpwFScyms6QxX7hji1DHN2ryUDFJYnQTHz/PS1zH/E Uh7Z3JSMTEWSqh4Se8zsgaBIsrUkGS2NG6w8JwgsmJa5dXS8g3mKTBX3TxMOxMERaky+qqIdZfR1 CtfhI2WWK7NcaZzWapzDgzu92vJh3j6VqVp8+rnJwPTwVNQTz8T4bD5uPEauJ+Rf2H/RWcrbmfXE jnLY+DRzUux/RuZ8QpHR8iH3KonshKAyB9H6/W3f56l9FNBon2vnhGDfNqKLfRYJ9qoyfELj7RXF noGIv2eGkxhjt/++I12x3aXpn6lBddhcpSSDEJbQZhZmg/E9AodlV3vpv+/1rx+00eTyMl1qO3dK WXRyxhDHSPZekqo/j8xrQdv45rpTaZfIHm9+fJ4fY25yeEbcNrcV5R8YTEOCFjM+jVj0ztsexlRE k5nrO4iIBtlBbIe3dCzL2frEcnSKfQcdy9Sf+dzecEV9EJDYidcjS89ZY5tdn7iMZfe4VPBm4OWq OqALiwFmsXsx35iY+uxM7AAbgp5sV7DDRiYWU4vYqOyCTikbjVI2qjLktUwb0JloBP+9xIxlFz3K bUsuJ52IGQcR+Qma5MenpcMCXcKt2gxoArO448ouu5SANZJ2bKjQcfmNc7GjMzW9cMvhTCPTnk3W cqlbgTnFfsZb6mVN+AwIZddEeikIU9N+LHhLSX7LLnuU25om5VeY8M2p83wR4Ty0i5kKuEf7zUeO Vt6m5hkBL7s2U65IvXiUi8U3ioj75cM7W2Quv/dl2TVJk/e+rKeWCkT33sRe2FnyTXkt1Z6XZRfz TJp5UhLGACvRxrKreCZtrAnlFLVcu+M90vESYtW9n3E9e8MOjjfmtYyfAilbUZ8YpocdpYju2DY+ Tcc+OOYkIKsbS/WAzG97aGUeR/j7WinwL7Ax8/FWVjYjLk+JZWTlYJfheHP14y2uaGqguTlBBB4t GGqa9rnfqaAqpgumO2u2FxbcH+uVlddJYT3e76PqWuaqHhnxzd97Ybgjq/TytMqoslapydj5Q7sE btVVSk3cQj2McCQHkATP7nENM6quYa5rdWoBepgPQjixLxizMaB1Zj5hZIuwBpY1f2bBGQ+v0gX2 1FvzwMjRsT6qqKUw1iVbKHYr6o31/HfsGngnbEQTKavBxT3WWT3+HtU11ik7BuGR402srq4GtWRn 6jIPtL+GZFD7eLMq6qfmJWAnMJHLYhVV1GgyqoklN4NjzYleTtUpXzpQy+dbtLhlvmj7WtxoGmuI sCf4NDttGZHQIM5o2RhZYuVn0zZMnQaI4BB/o+vM98/IYhMQavnO7tBrmUw0ijAPUcANtjYGKiip nUzIwVhzHS/g+AsvmQ+/eOp4dI04tvWssM3XnlHoh1DXRQrWD/290J+aC2QfYOZwwe7ICTmeg+3s cVnL5FVxWCaFc5nJkImFcHMG0xkGH3cNdcdDpl5k4AXxqfF1eHzFnAQba4FUI1jqiVobjCyEWPDH nBkbEXDp3TFPhyWOlBlBkUN2jMlByVFlf3ZU4HTD59beD6o43QWv+oAXCVN9u9Kw542PKzu7I8lp k92I6q2fGixg3tq0Od2tKDw5tDuc6gme8wPTsuAUBYkaYUa2F1L78sVB5wIgYTjsItgybm3cFliw Rx5+FL6fsKZ4J0bGFcYYPJp4FKFET3RuFPGIl/JWABcJX2gSxDECseK5IP37YXYcyGwUbmZfYpPd JK5/uvFc8B4JG+329D4ZVY4gjaRYwMvIqKDxx9tcGFgCBVPT7qBZBqI6N51BX7vsaf1eX3vQ+pO+ lHeXW/7pdnw1m71cCazp8/HIxrhiEAne+MkAn3psDWWcAViu+xgXBobqARvppwjrWVgVVxntOF1e MnfO42vVFWOBLHJmzcCVKkBOwaABFBKOC4NVh2EbFKj18fDq6rpSJiC/9SLWzUO1JV6hYmDrlFKZ 33gevRU8zLsgCiAc74nCUNeRnigwD0/VE112/nhOtisEosXriEI8borpqK9L7DBqPTqeGayiUrzQ XA5DK9wm8zcud/dTKzosHC4R8B1Xt5dPxzncZ4oigfxdk86EcuV/hS+R1a7xIGufl9q+FjdqrY4i vzpb4g5hXmEjODmokluGvDvcW+YHKFnIxFjGOzEWS5DfPRZu22OIKIewRwpKAHamFbRq6ZQrCACy AuEO0pgRFiq+cMVTngKQgg5n3IldURdOLuJE0BQUcQmuJ1tOCY2SLfdd4726TKDrOF8FpFz78vQb 0gQDhANC/JFGiHIwy40V2VcK3HxTNM4ToDQsgHvJ81cHszCIpIWZGZF9kdILCuDDAHNlwG1ClX0x 5plS/ThaIW1y+wdaGOp6xzKIY9O5qmE3haDG1OExlZddEXiDpaI0DKZ4ec4CM5ieEVNeLrGSJKqh oG2Fs6rwPYxviGEUMf57zPwZiQ4D9aHziwhcpEIiVa3wPYwvj8EPiSjjQ+EhPmHa6NQOK0fEsaVv LER7pUBKArIC9zC4OnWpbgbPhOqe46O4RJjZHmPRJFCgjX1gHcwVtR/hsfsbvhGsKehBVewcWXUK /GlYiHYBUqThuFmTl4qLqXjNEONMv/WnF9zayxpjxjKzlnvlaA8x/qDouB5BzpRCztco7PnT435E qC3zK8szE1BJwL1Mhug1eAIxa+5yDgoDOP8HAAD//+xXUW/aMBD+K1aeNqm0TtImEA2kTkzbyyQ0 6CbtzSQHsWTizDGl7Nfv7CQtoUkLtJMmrTwAsR37vvN3991FquDJt6FDaX/gfby+dMimHJqolsEx LNha6Mczk52h0YdNlE+U/ZnqrQDc8paJoTMRjGczuNPOhZlU5RrBsmW9ArLezdTMXlTT+FttpVoN O3SfTaTJ3UpERc5iGDq5ggLULTgjUn1mKRC2hEwT/ALFNBSEkQw2REEulSYLqYjGRQqYWBG5MCbq 0lBjBM8KNJAnQyekxodsrVOJLrwRiscp+cHBHoAOMLMJ7j90POpe9lzao+7MpZEXRpT+dCwiXHJ/ L4Efhn1ajh/gsW6keptDw2pEgGZbDLk5Nt899v+mg2Ov2TkjLEsIOgmULvD6ma7pwDMtLR9YVmxA NfzaYIPbxYY9HtBBj/ZnbhBRr50HLn4G3ivw4F1J4xj4LSQklYXuGWrUyBpQaoo0IHldkDCCniB4 F7BP10E4Hh8DbLRiWzI3Fq+kwbBQctV1Ga0I/NMQeP32qzk+REdnBM6X52STQva8w21WPiGjDF7L 3I7caYhUJs0ENMR1iNhhsZSK65QUIHAGL2m+JdMGVMxxuwnnBCd6r7tfB0pekExqUqxzIwQlEgMx Fhz14gATKpRjQA2k9Hi6d9jVOLmV5lddNDfjOxrUlnsSELjIClrQtc0z8e63069KZC/0CtpnSokR 3g4qtEBZT8jGEM5cTa3hCc6hXGN+M86qXzH/lZU9HLG/VgYbOS7swtzpuge0O67rd23zL7juPuc/ 4Zy9ID1ehEbvO3iqKgJ8a1SaRxR0o3NCZu1xiBf8VtE0C1ydKqm1wLJWwa81FJisbbhkcv9+3jzX 9NwYncUzprnMel+wWiLX3ycEK8GG3xrJY3Ba1Ht/Wa9NZmwY/SAaLw/GilWYhU3zdL5/zmNSBVdh GNheybY6jSxQp4adfrNabvuUsg06pn+sE0KBtcjkHqyR4wPMmOJLZqkf+Ngl20I1X05/o5GboYNF ObUCmeL/oO/3y+Y2X35l5hwtcxy/dK2eKL5Mcaf6cY4BKVdmC99WeAIWO7MpsASwgwypFZGFlHrn cbnW9pGWx8VSmP6zam/NK7bFTmT8WXEUxkjwDCZcx2ilj14vW+zSG1YB5zLZlpIo4/UK65rRHwAA AP//AwBQSwMEFAAGAAgAAAAhAB9YTWFcAgAA/AoAABEAAAB3b3JkL2NvbW1lbnRzLnhtbORVy27b MBC8F+g/EDwlB1vyI6ktRArSugUKFGjhJgjQGyutI6J8CEvKiv8+S0l2+kIaBegluUgQuTs7nB0t z85vtWJbQCetSflkHHMGJreFNDcpv7r8MFpw5rwwhVDWQMp34Ph59vrVWZPkVmsw3jGCMC7Z0m7p fZVEkctL0MKNbQWGNjcWtfD0iTeRFvijrkaUWwkvv0sl/S6axvEp72Fsyms0SQ8x0jJH6+zGh5TE bjYyh/61z8DH1O0yVzavA+e2YoSgiIM1rpSV26Ppp6LREcs9yPahQ2y12sc11WOqFSga6odWHe3G YlGhzcE5Wl11mwfESfxQ7V7AAHHIeAyFX2vumWghzQEmuOO3/h+aN6bmRV3tKEDdH4S0yO69xJpE FiknEzaJqH1pqbdXCmVesmsJJYT1QniqNI0n81G8HMWLy8lJMjtJ4vhb2JVGeimUo7zrFrmiRXJ3 sSbYeLGcvr2Yh7h2aQUbUSv/007gUn3B9vXV7xRQ6FaolL/rzH4Jt55H2Vl0CGtjsUvBv6WsYQNI /xT0eX2sMMb61n4U0CF2UHtygdVydvrm5H17Dp99ZK4UCGxna2S5JUQ0gYhv6VByINU+Se3g8j+F nQwWdvEChEWolMiB8dU6QRBKk0rSl4y3HyO0tYeCD5V6uImXL1nr0jr/RKlng6WeT5+/1OE+TVxF xk55heAAt8Czo/kxuzCuAWRHNIDCHPE0xekiYcKwz5/Wx0w6pmV7t4zZQNPPBg+Y59SJMG999l+m yWw6dHLPZ8/H4v8QdsDooCuyvxxddgcAAP//AwBQSwMEFAAGAAgAAAAhAONaSSeXBgAAVRsAABUA AAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU1vG0UYviPxH0Z7b2MndhpHdarYsRtoUqLYLepxvDve nWZ2ZzUzTuobao9ISIiCOFCJGwcEVGolLuXXBIqgSP0LvDOzu96J1yRpI1pBfUi8s8+8318zvnrt XszQIRGS8qTt1S/XPEQSnwc0CdverWH/0pqHpMJJgBlPSNubEuld23j/vat4XUUkJgj2J3Idt71I qXR9aUn6sIzlZZ6SBN6NuYixgkcRLgUCHwHdmC0t12qrSzGmiYcSHAPZHSyolPjSFpE0TLyNnHyP AY9ESb3gMzHQxIm7x4CDg7qGyKnsMoEOMWt7wCrgR0NyT3mIYangRdurmY+3tHF1Ca9nm5hasLe0 r28+2b5sQ3CwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DqlaWMs1Gf63eyWmWQPbrPO1u rVlruPgS/ZU5mVudTqfZymSxRA3Ifm3M4ddqq43NZQdvQBbfnMM3Opvd7qqDNyCLX53D96+0Vhsu 3oAiRpODObR2aL+fUS8gY862K+FrAF+rZfAZCqKhCC/NYswTtTDYYnyXiz4gNJJhRROkpikZYx8i uYvjkaBYc8DrBJfe2CVfzi1pZkj6gqaq7X2YYsiKGb2Xz354+ewJOr7/9Pj+z8cPHhzf/8kScnZt 4yQs73rx3ed/PfoE/fnk2xcPv6zGyzL+tx8//fWXL6qBkD8zcZ5/9fj3p4+ff/3ZH98/rIBvCjwq w4c0JhLdJEdon8egmLGKKzkZifPtGEaYlndsJqHECdZcKuj3VOSgb04xy7zjyNEhrgVvC6gfVcDr k7uOwINITBSt4Hwjih3gLuesw0WlFW5oXiUzDydJWM1cTMq4fYwPq3h3ceL4tzdJoXLmYeko3o2I I+Yew4nCIUmIQvodPyCkQrs7lDp23aW+4JKPFbpDUQfTSpMM6ciJptmmbRqDX6ZVOoO/Hdvs3kYd zqq03iKHLhKyArMK4YeEOWa8jicKx1UkhzhmZYPvYBVVCTmYCr+M60kFng4J46gXEGhtFVJ8JEDf ktNvYChZlW7fZdPYRQpFD6po7mDOy8gtftCNcJxWYQc0icrYD+QBhChGe1xVwXe5myH6GfyAk4Xu vk2J4+7Tq8EtGjoizQJEv5kIbUWo1U4FjmnyT+WYUajH1voXV46hAD7/5lGFT9/WQrwJPakqE7ZP lN9FuJNFt8tFQN/+mruFJ8kegTCfbzzvSu67kuv950vuonw+a6Gd1VYou3pusFOxmZHjxSPymDI2 UFNGdqSZkiU0iqAPi3qjOSKS4syURvA1K+wOLhTY7EGCq4+pigYRTmHCrnuaSCgz0qFEKZdwtDPL lbQ1HqZ0ZQ+GTX1ksAVBYrXLA7u8opfzk0FBxrSb0Jw/c0YrmsBZma1cyYiC2q/CrK6FOjO3uhHN 1DqHW6EyOHFeNVgsrAkTCIK5Bay8Cod0zRpOJpiRQNvdNt/cLcYLF+kiGeGAZD7Ses/7qG6clMeK uQyA2KnwkT7mnWK1EreWJvsa3M7ipDK7xgJ2ufdex0t5BM+8pBP3RDqypJycLEFHba/VXG56yMdp 2xvDoRa+xil4XeqhD7MQbod8JWzYn5rMJstn3mzlirlJUIeLCmv3OYWdOpAKqbawjGxomFdZCLBE c7LyLzfBrBelgI30V5BiZQ2C4Y1JAXZ0XUvGY+KrsrNLK9p29jErpXyiiBhEwREasYnYx+B+Haqg T0Al3E2YiqAf4CZNW9u8cotzlnTl+yuDs+uYpRHOyq1O0TyTLdzkcSGDeSqJB7pVym6UO78qJuUv SJVyGP/PVNH9BK4KVgLtAR/ucgVGOl/bHhcq4lCF0oj6fQGTg6kdEC1wGwuvIajgRtn8F+RQ/7c5 Z2mYtIYTn9qnIRIU+pGKBCF7UJZM9J1CrJ71LkuSZYRMRJXElakVe0QOCRvqGriqe7uHIgh1U02y MmBwJ+PPfc4yaBTqIaecb04NKXqvzYF/e/KxyQxKuXXYDDS5/QsRK7qq3W+25723rIh+MRuzGnlW ALNSK2hlaf+KIpyz1dqKNafxcjMXDrw4rzEsFgNRChc+SP+B/keFz4gJY91Qh3wfaiuCnxo0MQgb iOpLdvBAukDaxREMTnbRBpMmZU2bjU7aanmzvuBJt+B7wthasrP4+5zGLoYzl52Tixdp7MzCjq3t 2kJTg2dPpigsjfOTjHGM+V2r/MMTH90FR2/BBf+EKWmCCX5VEhhGz4HJA0h+y9Fs3fgbAAD//wMA UEsDBBQABgAIAAAAIQCjPUhHjggAALMhAAARAAAAd29yZC9zZXR0aW5ncy54bWycWklvI9cRvgfI fxB4jqy3L4w1xlvjBDNJYDmX3FpkSyKGZBPdLWkmvz7VJNsaxR8NI7qIfNVVXa/2hd//8GW3vXpp +2HT7W8X/Du2uGr3q2692T/eLv71c712i6thbPbrZtvt29vF13ZY/PDhj3/4/nU5tONIjw1XRGI/ LLvbxXO/Xw6rp3bXDNe7zarvhu5hvF51u2X38LBZted/izNGf7t4GsfD8ubmjPRdd2j3RO2h63fN OHzX9Y83J8zcrZ537X68EYyZm77dNiMxPDxtDsNMbff/UqNXPc1EXn7rEi+77fzcK2e/9eT5uq9d v/4F4/ewNyEc+m7VDgNJdrc9XXfXbPYzmWH7e+ic5Plxc983/ddviHwgtb1s2tcr+tcQpf0k6O3i Zjr/T9ft6PzQ9isSNNmCYSfA2Derzz+1L5vJRobjs+v2oXnejj8393djd5ipWeZOGE9fD0/t/qii f5PVzHAl9Am+emqI5tj2d4dmRRdN3X7su+383Lr7ezembnfoSQ5nDPrWjMd3k6muh4nh6cNPXTfO aIw5L2JQJ4wJ+gZhTEdjIEQabcIFSDYcQrQWRkKI4cVkCHFaVA8hwegqICQqIgchyTKFqWWlE4YU GW1C1DjTXEMcTn8e8sa5TA7KjXNV+FnT77XAuebxbCP/AxGq+Ah5E0ZxKAMuVSxQC/SaoqDmyKgD L/A9hosCbYeTXV+Qm1VSYhlY5aKF77G6RIzjtPP4ps74jKl5JbD18mCkx1qIXGlMLXKLrYpHJRzW T9SZYVlnySLGKcJfsIOqUoX+IxiPHkPIFDXUqRBSc8ibIL1VKGtCyakizQnDuYVeIox1GeNE4QyU gUhSKagfkYVJ0EJElj5hGRRuIuRAkgfXcyR/73NSaseg/0hpDPZ6qckbYQyRRrCEqRlJkRlJVFqj cISVTioPI4V0thZMzdscMQcU93C8lkm5C+8p0l/gujIjoKwVs1pDDhTnLEMbJYhKAklHKVY4lAEZ TsB5gSAJRz6lWcG5URlrsP8ox0yB/qMcTwXz5kSw+D5eFByvldeuYIkGES/wFjnDGUMlaz2WdWbe Qm9UmYcAvURVxiukpjmTCUpHcykMxtGKOZhltDZCQLvWhlkBJUooAcde7SULUKI6CFahjeogbUnI EnVQtWoIIS3g3Kgj5xHGKh2FcVg6UYeAb5qIGpZ1koxBzekkSTyQa/KRCq1XJxMVlkFWDOdtXdgF 29HkvwXfpwgRMAdFZWYg18U6je9TjZIQx3BbOLQDCtfFQEs0UvBLEG1whDXScgd5I4i9ANHWzj3G +8xktHUB2psxlmOdToCK72ONUVgGjvMMM63xUmKfM1kGAy3EZEPJHmnOFGM0jDumco+zpqlWM3gf y5jFOdgyqgKgvVnOhYXeSBCKiohrq4zHdTylbRExjhUJR2Vrqd6Accc66TPmjSrVCO3ARh5w5e0Y dSxQ204w6S5AhMUVsZPC4ojkpKTEjeTmpE4MWpWjjB6gDJxSGVc1TpkkMdeKJIepUZHmYLR01GNc uKmnCgVa7+Wu2gWZcQXpouAXuE6y4HjgiqwSattV6vWgRD3FfpxLPBcS+7YXmughzXnJE+4KvDTU t0EcxZSDPuepbw1QolPThn3Ba0VNE3yPVTFias4kXFv6oByeBVDQsRLGa59MxR2YT9YUrIVki4XS CYw8Fd4n8EseHBRNFqD1BsN9hDGRIMXBfBqMyBVzYI3QMO4EaySe4hDEC9g7B/IsXHERpBZo1yEo kTHXVLsUqJ+QRVYYpzB24aZVOOwLoQqvofVGRsKBcouM4j+UAYVri7upKLTEs4AorVaYA61LhfYW ta54UhJpmMdgtIzWWDxDiU7QHAf5XPTUhSYICcxV/J4kvcfSSTLgKBYTpVpoiTFZiSclMXODszNB koHZOWZLxTe8D9kOnubFohPuNSNFUQ/1kxh1TdBPEzWUHkM4oxCLeKNineMeI2nSArTR5KjggjdN lDJw3k6UGAqmFmXAVpUiWRXGScLhqW7KXOMaNhUSApYBzW6xJaaqK66EMqdpOLSqzGXBHXKW3Eto vZkmZjhSZEVFEn6Posk2jORZc2qnkLaz1h5HimzJEKB0cjQB9z850WiuwPdkmRi+abUqQP8p0jgP o3LRLOGeqWgh8dSweJkklAG5CGcCcV28rfMW5X3PVAIreCpVgq4JZowSyHqh5kriGlf4JQmNM20p 4kJ3SJAaYKSggVDVmLdCHSWMFJVqPjxdocEcz9BCKmUmXDlUwRWe3VbJjcQcSJpfw+hfJYVrzAFN oi3GMSoxmGUqJVpcCVUnaGCELKQ6ExK00eqoo4R5rlJKxxVxpbk/tsRKGyhsITVzStCQN5pt2KMd 3JzWd7TH2y2n/es/+/lTpV3g1e60nkzN7r7fNFefpg0tLf92y/v+c9zsZ/h9S5vi9lvI3fP9DLy+ PgEG2nBuK+0bZwAtZ0+Q9WY45PbhSHj7qekf3ygfBbhb9vCUtp9/+4XatCxt+7/03fPhRPW1bw5/ 3a/peH4hp0nuCbbZjx83u/l8eL6/m7H2tKj9BvS8X//jpZ+Qbt4E9LocabfeThL62Owf5+3mur2e y//Vtr+b9u/tp+ZwoMUqPXL/yG8X283j08gX9HWkb+um/3z8cv8ozjBxhNG3CXb80qymm9HT5w/T A6eP9NT5w9uZnM/k25maz9TbmZ7P9NuZmc/MdEa747bfbvafac89f5zOH7rttntt1z/Oh7eLXx1N 8qLfJTw1h5b0Om2oycC608F5ZT1cvSzbL7TebtebkX7acNisd82X24Vip8L1/PS2+do9j++enShN Dx/enV6tm7GhZflRVe+QSXW/4uV1uW5XGzLIu6+7+7eF959OjG83w3jXHpq+Gbuernxc0f/5SJko tadfW3z4LwAAAP//AwBQSwMEFAAGAAgAAAAhACf+mD85AQAApAIAABQAAAB3b3JkL3dlYlNldHRp bmdzLnhtbJRSy27CMBC8V+o/RL4Xp9BnRIKEEKeeWvoBxt4QS7bXsk1S+PouCW3p41BOXu/OjGd3 PZ29WZO1EKJGV7LrUc4ycBKVdpuSva6WVw8si0k4JQw6KNkOIptVlxfTruhg/QIpETJmpOJiEUrW pOQLzqNswIo4Qg+OajUGKxJdw4ZjXWsJC5RbCy7xcZ7f8QBGJHIQG+0jO6p1/1HrMCgfUEKMZMSa Qc8K7VhFHpVu4/HMukKrkk3uJzfj+/HjbV9fo9otdEu1Vhjqn/ED2orwBHX6yOaf2We9af5Ir9D/ xs4xJbQ/8uRnrsLhjfTFcTRZRsC4LxnNnwIvJM26jyUapLmKbcLBhjlxdh5z/c3Redxw2vk5VN4v oW96CKvpcPZ7QZ+01XtYYpgH7CIEWgDVT/5W9Q4AAP//AwBQSwMEFAAGAAgAAAAhAKuIgGpTAQAA iwIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIySX0vDMBTF3wW/Q8l7m3RVGaXtQGVPDgQ3Jr6F5K4NNmlI4rp9e9M/qyv64GN6zv3lnJtm q5OsgyMYKxqVozgiKADFGi5UmaPddh0uUWAdVZzWjYIcncGiVXF7kzGdssbAq2k0GCfABp6kbMp0 jirndIqxZRVIaiPvUF48NEZS54+mxJqyT1oCXhDygCU4yqmjuAOGeiKiEcnZhNRfpu4BnGGoQYJy FsdRjH+8Doy0fw70ypVTCnfWvtMY95rN2SBO7pMVk7Ft26hN+hg+f4zfNy9vfdVQqG5XDFCRcZYy A9Q1ptjVRrAq2AuoIMNXQrfEmlq38fs+COCP55k3oCUVKsO/Xd2ggaPoXq1Iesd09Df3RYfrgQc+ ejoUvSj75Ol5u0bFgsR3YUxCEm/JMiX3KSEfXcDZfFdl+CDHmP8mJmROvACKPvH89ym+AQAA//8D AFBLAwQUAAYACAAAACEAPBEL3fQIAACGRwAADwAAAHdvcmQvc3R5bGVzLnhtbLxc33PTOBB+v5n7 Hzx+59omXAoMgWkLHMwAx5F27lmxlcaHY+Vsh1L++lutbEWxrXi3du+ptSztt9of3yqpti9f/9ik wXeZF4nK5uHZb6dhILNIxUl2Ow9vrt89eRYGRSmyWKQqk/PwXhbh61e//vLy7kVR3qeyCEBAVrzI 5+G6LLcvTk6KaC03ovhNbWUG71Yq34gSHvPbE7VaJZF8o6LdRmblyeT0dHaSy1SUAF6sk20RVtLu KNLuVB5vcxXJogBtN6mRtxFJFr4C9WIVvZErsUvLQj/mX/LqsXrCH+9UVhbB3QtRRElyDYrDFjdJ pvL3F1mRhPBGiqK8KBLR+XKtZ3W+iYrSkXaZxEl4ohGLnyDzu0jn4WRSj1xpDQ7GUpHd1mOxfPLm ravJPJTZk5uFHlqC3Hko8ieLCy3sBLdZ/3S2uz3YPDyhKlsRgeFAjFiVEhwI/tBC00Q7enI+qx++ 7lIYELtSVSAoAMBcsfDYsDj4Fby8MFECb+Xqo4q+yXhRwot5iFgwePPhS56oPCnv5+Hz5xoTBhdy k7xP4ljqoKzGbrJ1Esu/1zK7KWS8H//rHYZYJTFSu6wE9WfnGAVpEb/9EcmtDjEQnQnt4c96QarF Fg4OKrRL9tqYgQYqDv5bQ54ZH3airKXQaRSg/keBcNe7wUATvSN3AyiXpet0uIinw0X8PlwEBu8w W5wP1wLIc6hHTGw4UUl3aqkiE3yuHabPj4SsXtGKot4VraDpXdGKkd4VrZDoXdGKgN4VLYf3rmj5 t3dFy51HV0QCiasZRVO0Bimxr5MylXr9UQI6G0h1VakJvohc3OZiuw50YW2qfYwsF7tlSVMV6fTh ZLkoc5Xd9loEqrNO3Qdz8tvNdi2KBE40PaafDDT9tVimMvgjT+JeqN9N8LX2hAeTzhL2JRWRXKs0 lnlwLX8YjzLWf1bBwpwyepUb6NaPye26DBZrLLm9YDOP0f2WMPI/JgXa4GgyzTxb6RNO8uHME5d+ 4Z9knOw2tWkIp5GZ4XOGmxsQqOJxEz3VLmpnV+8utAMoWzDlgr8FlE/Q3xQXvnztY4r+phQ9UD5B f1O4Higf4+O4f9lM80bk3wJSep2zc/dKpSpf7dI6B3rp4ZydwRaCtgV2Elv5JJI4Z2fwAX0GF1EE n9woccr2xZ5HGShsdxgUTDb6XthOadDeGWNHbAc1sCYMrGFcywBik+5X+T3RXzxxiwGytD1r9qbz 1GMBKEGkM/RfO1X2n6EnHs6jonzI4OuSQgY0tKkn86hoVTyZesfw8bDCxwAaVgEZQMNKIQPIEx/+ M4+tiXSQ4cWRgcWmZVvFMOzIzHzOZmYLxCsBI9VNwvnLk73+WGjXTQIK20HtuklAYXunUcts3SRg jVY3CViequH3kcupnE2x66YLZE8ChB2NQ94EoHHImwA0DnkTgIaTdz/IeORNwGJzg+VUl7wJQDiF 81HfArnkTQBic4Nhu+o7o7ruoZTjH25HIG8CCttBbfImoLC94yNvAhZO4URCA8tSHQFrHPImAI1D 3gSgccibADQOeROAxiFvAtBw8u4HGY+8CVhsbrCc6pI3AYhNDxbIJW8CEE7hcEMneWPWPzp5E1DY DmqTNwGF7Z0GodpDKgGL7aAGliVvAhZO4QRDhYXBzdnUOORN2NE45E0AGoe8CUDjkDcBaDh594OM R94ELDY3WE51yZsAxKYHC+SSNwGIzQ2d5I3J+OjkTUBhO6hN3gQUtncahGp5joDFdlADy5I3AQvj ZTB5E4BwykOBODsah7wJOxqHvAlA45A3AWg4efeDjEfeBCw2N1hOdcmbAMSmBwvkkjcBiM0NneSN OfLo5E1AYTuoTd4EFLZ3GoRqyZuAxXZQA8tSHQFrHPImAGFgDiZvAhBOeQAQZhHHTeOQN2FH45A3 AWg4efeDjEfeBCw2N1hOdcmbAMSmBwvkkjcBiM0N+p4t3BclX0898wQB9Z5BfauBDDjxOIkKWG3w q1zJHDqZZP/tkIGA9Q4ZiJ7woG7xUqlvAe1i99QTIGSoZJkmCq903+MtHacRYXp+pJPg+s+r4L1p gGmtw5A6vHkD3UNuuxC2J+nGIdCzvN9Cy862vlmupUGDkO7rqlqAsA/tAzQEVW09erHu84GJ2FRV DePfbStU/B163uJ6zunpdDY9fVb1RkCvmBbidmFBy9Ufl1X7E74GjRG4rWq0Bl0j6Kg6omp1Yd7e YcLr8k3FPbfqUfl9S0e9hep2/f4MZuYd3PGEIb/epb5JfkRnvGl+1MYBTjFR0VYQmrtQpT4N7a0s nF0uU+MN+OVDph0GzYH4FzgTGPEPYcTC+yuZpp8E+q5UW//UVK5K8/bsFKtpQ9RSlaXa+NfneNkc NekSACZ2lTGPehN+22e7zVLm0C12xP6fla5C2NV2GN7m3qxxt81P0B6jn2p1v24HqWeTDVoDkgx7 Apphi29MuwDqtBTQrven7r5rpSO0Gn6rx63AK8if4TF0mN3Pnk8uL54aqb72RwyqqvnxqX3obn6s Gi3hx0EH6Ty8gk5WlYpC+xG7Q50hE/37BtA6Y386DaB1j0yrARQWg4s41BPtCohi7L9sMuWhrf0O DPa+aHixk8Bwg50+ZfrT77yKmh/F7Ez72lS4Uhvdz7w/ADQNKrJMQdOrbkHN7bmkKzf8Vh1Cp73W 3Dcln82MpwonJs1Yv3G6eaIyTidTOHYpdXdRl0nc6u2GliN3H6SPY6UWYXBJYm9f6PbCTbr2NWP9 9j04VxxJ7qZlmtFYvUeGHprgDtbYKU4x2oPPaEdjFT5C/COjdqV1wrWopnRFbMsmGcR2XeVaLzti usJ/7LCuqHRp9nBVwM/Rg9Ddii8Oqzn+UHRstreJ325jByLPQN2RZTsdmkawL9AL8A8O4F8e4K9k KvOze4u3qv/zYM828G8SyAedB34Y6jbHpUhTpbqPj9U7/gHSEboPE7IZD78iRBf8T5ZtnmWuxVpt hHOA3A9ExTysnlDDPUcOKdzUwtI0cDOWXc/5s9l/xnFT2sEaO58f2d7kmgRki0fI4tV/AAAA//8D AFBLAwQUAAYACAAAACEAgJ1ECeEBAAApBgAAEgAAAHdvcmQvZm9udFRhYmxlLnhtbJyUwW6jMBCG 7yv1HZDvLYbQbhOVVN3sctzDKvsADgzBEraRxwnN2++ACTkk2YaAhMSMGWY+/7/f3j9VHezBojQ6 ZdETZwHo3BRSb1P2d509vrIAndCFqI2GlB0A2fvy4dtbuyiNdhjQ9xoXNmWVc80iDDGvQAl8Mg1o ypXGKuHo1W5DU5Yyh58m3ynQLow5fwkt1MLRv7GSDbKhWntLtdbYorEmB0RqVtW+nhJSs+XQXdAu tFDU9UrUcmNln2iENggR5faiThmPecaf6dndCZ91TxZ2FfJKWAQ3LuQ+XAol68Mxiq1E9IlGurw6 xvfCSrGpwadQbimxww1P2S9OV5xlzEeilCUU+FiNkZia8lc0rJmNEdoeaqyv0y+J5n0dilCd4au+ z9DvzxmJtVSAwW9ogz9GCY/qnEjMX4jEM/HoyMwmEbF93Z7gBCLxxzg/TbKiUb6/Jsf5T0TmXxPx dW4nsiLxmVrgFXH8IBTzO8WhTAFWX1BHKT+huCCNiOY+k0Z2SRo3gJgsDVHR1v0HQ+eOThPJ/R7R xq3tDtaHBqYoZFD27OSZUeveRSeF9A4hp133DOe9riYoRCg6PK6R6TziuXSemXZ63OeVc4nwZHTP FBJfnx7DMYLLfwAAAP//AwBQSwMEFAAGAAgAAAAhAONVOGjyAQAA8QMAABAACAFkb2NQcm9wcy9h cHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFNNbxshEL1X6n9Y7T3G dh0nsjBR5ajKoU0seZOcp+ysjcwCAuLG/fUdduMNbnoqp/nS4/HmwW9eW10c0AdlzbKcjMZlgUba Wpntsnysvl1cl0WIYGrQ1uCyPGIob8TnT3ztrUMfFYaCIExYlrsY3YKxIHfYQhhR21Cnsb6FSKnf Mts0SuKtlS8tmsim4/Gc4WtEU2N94QbAskdcHOL/gtZWJn7hqTo6Iix4ha3TEFHcJzqas6HAKxtB V6pFMabykPA1bDGIL5z1AX+2vg7iej7hrA/5agceZCTxxOVsesVZVuBfndNKQiRdxQ8lvQ22icVD p0CRADjLRzipskH54lU8JiJ5yr8rQ1Rml5z1EXHzsPXgdkFMponhkPKNBI0rerxoQAfk7L3A7xDS YtegiDI/xMUBZbS+COo3rXZaFj8hYJJsWR7AKzCRpEtjfdLF2oXoRaWiJmzq9XkX5mN5rGaCRKNZ Cs4HU7HnQI1zdt0N4aGht8V/kJ3kZDsOPdWMThYOd/yFurKtA3MkV+wVFBuF5MtQ3GP8Zf0+0ELf +mkD+/DoKnubTPSm7Hkxs8OziruNA0lLm0+v5rkxshbfkH+wpk2fAN8L/I624HW6lUxltlifZj42 ktWe+h9MbhiN6XTeOtXIH8PXEn8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAOvTUqh0AQAAowUAABMA AAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat/MA AABOAgAACwAAAAAAAAAAAAAAAACtAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAmzu1wwkB AAC0AwAAHAAAAAAAAAAAAAAAAADRBgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQIt ABQABgAIAAAAIQD9Afc9yBIAAGHLAAARAAAAAAAAAAAAAAAAABwJAAB3b3JkL2RvY3VtZW50Lnht bFBLAQItABQABgAIAAAAIQAfWE1hXAIAAPwKAAARAAAAAAAAAAAAAAAAABMcAAB3b3JkL2NvbW1l bnRzLnhtbFBLAQItABQABgAIAAAAIQDjWkknlwYAAFUbAAAVAAAAAAAAAAAAAAAAAJ4eAAB3b3Jk L3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAoz1IR44IAACzIQAAEQAAAAAAAAAAAAAA AABoJQAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAJ/6YPzkBAACkAgAAFAAAAAAA AAAAAAAAAAAlLgAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAq4iAalMBAACL AgAAEQAAAAAAAAAAAAAAAACQLwAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEAPBEL 3fQIAACGRwAADwAAAAAAAAAAAAAAAAAaMgAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAh AICdRAnhAQAAKQYAABIAAAAAAAAAAAAAAAAAOzsAAHdvcmQvZm9udFRhYmxlLnhtbFBLAQItABQA BgAIAAAAIQDjVTho8gEAAPEDAAAQAAAAAAAAAAAAAAAAAEw9AABkb2NQcm9wcy9hcHAueG1sUEsF BgAAAAAMAAwAAAMAAHRAAAAAAA== --_002_5BCBA1FC2B7F0B4C9D935572D90006681521304DDEMUMBX014nsnin_-- From nobody Wed Oct 1 06:28:00 2014 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 AF0911A038E for ; Wed, 1 Oct 2014 06:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-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 b65-V77ezLcH for ; Wed, 1 Oct 2014 06:27:55 -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 9F23D1A0324 for ; Wed, 1 Oct 2014 06:27:55 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52512 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XZJwb-00018w-Q3; Wed, 01 Oct 2014 06:27:54 -0700 Message-ID: <542C0155.7050908@usdonovans.com> Date: Wed, 01 Oct 2014 08:27:49 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <542AC192.9090600@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681521304D@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681521304D@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/H_03hdv3L74xPNsjB6b3QBuEdoQ Subject: Re: [Dime] DOIC #70 - Proposed resolution to core issue 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, 01 Oct 2014 13:27:56 -0000 Ulrich, Yes, but the proposed resolution for #70 is that a DOIC supporting agent strip host overload reports from requests that did not have a destination-host AVP. The justification for this has been that the client might not send to the host and that would cause the client to save extra OCS entries. The client will need to be prepared to handle overload state received in this type of a request when there is not a DOIC supporting agent, so there is no savings in logic to be implemented in the client by having DOIC agents strip host reports. In addition, the client is the best place to determine if a host report is useful or not. In the many cases the client will send subsequent host reports to the server. This will be the case in many session based applications where the first request is realm-routed and subsequent requests are sent to the server that handled the session initiating transaction. I'm ok with adding wording to the specification along the lines of "the client SHOULD save the OCS state for all received host overload reports. The client MAY not save the state if it knows that it will never send a host-routed request to the server. This might be the case, for instance, when the client always sends realm-routed request for the application." Regards, Steve On 10/1/14, 3:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > I agree that there may be cases where the agent that selects the server does not support DOIC, and consequently transparently forwards a host-type OLR to the client which then receives a host-type OLR in response to a realm-type request. > > The example flow in Appendix B, however, assumes that the agent supports DOIC. > > Please find the proposed modification attached. > > Ulrich > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Tuesday, September 30, 2014 4:44 PM > To: dime@ietf.org > Subject: [Dime] DOIC #70 - Proposed resolution to core issue > > All, > > The core issue raised in issue #70 is whether a client can receive an > OLR of type host when the request sent by the client was realm routed. > > I do not support the suggested change as there are scenarios where > clients MUST be prepared to receive the OLR of type host when the client > does not do server selection. This is required for the scenario where > agents do not support DOIC. If the request does not contain a > Destination-Host AVP then agents will be responsible for server > selection. An overloaded server will send an OLR of type host that > will find its way back to the client. > > It is true that this might cause unneeded OCS entries in the client in a > scenario where the client will never do server selection for that > overloaded server. This concern can be addressed by making it up to > local policy whether or not the client saves OCS for the overload > report. If the client knows that it will never do server selection for > a server indicated in a host OLR then the client can choose to not save > the overload report. > > Based on this, I propose that we close issue #70 without changes to the > DOIC specification. > > The discussion about the handling of a mix of overload abatement > algorithms should continue. We can open a separate issue if needed to > address that functionality. > > Regards, > > Steve > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Oct 1 06:34:06 2014 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 27DD91A044F for ; Wed, 1 Oct 2014 06:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-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 2VAnckDgcdhy for ; Wed, 1 Oct 2014 06:34:03 -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 2B06E1A0410 for ; Wed, 1 Oct 2014 06:34:03 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53367 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XZK2a-0006Q2-76; Wed, 01 Oct 2014 06:34:02 -0700 Message-ID: <542C02C5.40202@usdonovans.com> Date: Wed, 01 Oct 2014 08:33:57 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <542AC192.9090600@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681521304D@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681521304D@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/WNAhifsuZSdQc-W87gZfezoAWg8 Subject: Re: [Dime] DOIC #70 - Proposed resolution to core issue 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, 01 Oct 2014 13:34:04 -0000 Ulrich, I'm ok with your proposed wording for step 4 in the diagram that the agent MAY removed the host overload report. I just don't think it should be a MUST. Regards, Steve On 10/1/14, 3:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > I agree that there may be cases where the agent that selects the server does not support DOIC, and consequently transparently forwards a host-type OLR to the client which then receives a host-type OLR in response to a realm-type request. > > The example flow in Appendix B, however, assumes that the agent supports DOIC. > > Please find the proposed modification attached. > > Ulrich > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Tuesday, September 30, 2014 4:44 PM > To: dime@ietf.org > Subject: [Dime] DOIC #70 - Proposed resolution to core issue > > All, > > The core issue raised in issue #70 is whether a client can receive an > OLR of type host when the request sent by the client was realm routed. > > I do not support the suggested change as there are scenarios where > clients MUST be prepared to receive the OLR of type host when the client > does not do server selection. This is required for the scenario where > agents do not support DOIC. If the request does not contain a > Destination-Host AVP then agents will be responsible for server > selection. An overloaded server will send an OLR of type host that > will find its way back to the client. > > It is true that this might cause unneeded OCS entries in the client in a > scenario where the client will never do server selection for that > overloaded server. This concern can be addressed by making it up to > local policy whether or not the client saves OCS for the overload > report. If the client knows that it will never do server selection for > a server indicated in a host OLR then the client can choose to not save > the overload report. > > Based on this, I propose that we close issue #70 without changes to the > DOIC specification. > > The discussion about the handling of a mix of overload abatement > algorithms should continue. We can open a separate issue if needed to > address that functionality. > > Regards, > > Steve > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Thu Oct 2 01:31:16 2014 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 0B11F1A002D for ; Thu, 2 Oct 2014 01:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 XzW1CPN226x7 for ; Thu, 2 Oct 2014 01:31:12 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB6891A01A5 for ; Thu, 2 Oct 2014 01:31:11 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s928V9qt027793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Oct 2014 08:31:09 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s928V6D8012562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Oct 2014 10:31:08 +0200 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 2 Oct 2014 10:31:06 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.218]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0195.001; Thu, 2 Oct 2014 10:31:06 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC #70 - Proposed resolution to core issue Thread-Index: AQHP3LzxVwlySCWp3U+Xg2cvYp/Vlpwa49oAgAA4IoCAAUxH0A== Date: Thu, 2 Oct 2014 08:31:04 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668152131BD@DEMUMBX014.nsn-intra.net> References: <542AC192.9090600@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681521304D@DEMUMBX014.nsn-intra.net> <542C0155.7050908@usdonovans.com> In-Reply-To: <542C0155.7050908@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5367 X-purgate-ID: 151667::1412238669-00001FC1-02F1E399/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PfDlgANJ3bzAMoOfaWYnworR-O8 Subject: Re: [Dime] DOIC #70 - Proposed resolution to core issue 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, 02 Oct 2014 08:31:15 -0000 Steve, please see inline. Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Wednesday, October 01, 2014 3:28 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Subject: Re: [Dime] DOIC #70 - Proposed resolution to core issue Ulrich, Yes, but the proposed resolution for #70 is that a DOIC supporting agent=20 strip host overload reports from requests that did not have a=20 destination-host AVP. yes that was the original proposal; however during discussion we came up with a compromise that allows (rather than mandates) the agent to strip host type OLRs. The justification for this has been that the=20 client might not send to the host and that would cause the client to=20 save extra OCS entries. still valid. The client will need to be prepared to handle overload state received in=20 this type of a request when there is not a DOIC supporting agent, so=20 there is no savings in logic to be implemented in the client by having=20 DOIC agents strip host reports. saving is not in logic to be implemented but in processing to be performed. This brings me to another (but related) issue: When receiving an answer the client (that supports DOIC without extensions) must be prepared to find lots of OC-OLR AVPs in the answer. The client needs to check every single OLR to see whether it is valid (sequence- number) and supported (report-type). If neither valid nor supported the OLR is silently discarded. An optimization for processing to be performed by the client would be to a) prohibit nodes to send OLRs to clients which the clients do not support, and b) allow clients that do not support any extension to check only the first OLR and silently discard all other received OLRs.=20 In addition, the client is the best place to determine if a host report=20 is useful or not. In the many cases the client will send subsequent=20 host reports to the server. This will be the case in many session based=20 applications where the first request is realm-routed and subsequent=20 requests are sent to the server that handled the session initiating=20 transaction. I do not think ist a good idea to spam the client with useless Information I'm ok with adding wording to the specification along the lines of "the=20 client SHOULD save the OCS state for all received host overload=20 reports. The client MAY not save the state if it knows that it will=20 never send a host-routed request to the server. This might be the=20 case, for instance, when the client always sends realm-routed request=20 for the application." ...should save all... is ok (for all received valid and supported OLRs), but then ...may silently discard subsequent (i.e. all except the first) OLRs. Agents that add realm-type OLRs must add them before the non stripped host-type OLR; nodes that add extension-type OLRs must not add them before host-type or realm-type OLRs =20 Regards, Steve On 10/1/14, 3:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > I agree that there may be cases where the agent that selects the server d= oes not support DOIC, and consequently transparently forwards a host-type O= LR to the client which then receives a host-type OLR in response to a realm= -type request. > > The example flow in Appendix B, however, assumes that the agent supports = DOIC. > > Please find the proposed modification attached. > > Ulrich > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Tuesday, September 30, 2014 4:44 PM > To: dime@ietf.org > Subject: [Dime] DOIC #70 - Proposed resolution to core issue > > All, > > The core issue raised in issue #70 is whether a client can receive an > OLR of type host when the request sent by the client was realm routed. > > I do not support the suggested change as there are scenarios where > clients MUST be prepared to receive the OLR of type host when the client > does not do server selection. This is required for the scenario where > agents do not support DOIC. If the request does not contain a > Destination-Host AVP then agents will be responsible for server > selection. An overloaded server will send an OLR of type host that > will find its way back to the client. > > It is true that this might cause unneeded OCS entries in the client in a > scenario where the client will never do server selection for that > overloaded server. This concern can be addressed by making it up to > local policy whether or not the client saves OCS for the overload > report. If the client knows that it will never do server selection for > a server indicated in a host OLR then the client can choose to not save > the overload report. > > Based on this, I propose that we close issue #70 without changes to the > DOIC specification. > > The discussion about the handling of a mix of overload abatement > algorithms should continue. We can open a separate issue if needed to > address that functionality. > > Regards, > > Steve > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Fri Oct 3 14:11:35 2014 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 A28531A7D80 for ; Fri, 3 Oct 2014 14:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 TCTPXBVelhWj for ; Fri, 3 Oct 2014 14:11:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D136C1A8033 for ; Fri, 3 Oct 2014 14:09:45 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s93L9g0e031326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 Oct 2014 16:09:44 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668152131BD@DEMUMBX014.nsn-intra.net> Date: Fri, 3 Oct 2014 16:09:42 -0500 X-Mao-Original-Outgoing-Id: 434063382.465898-58fed1f6a1d79837c0a66986e1e164a6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <542AC192.9090600@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681521304D@DEMUMBX014.nsn-intra.net> <542C0155.7050908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152131BD@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/JZCg0vX-0reMj6bfFjqwL2iXafY Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC #70 - Proposed resolution to core issue 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, 03 Oct 2014 21:11:33 -0000 One comment inline. On Oct 2, 2014, at 3:31 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > Steve, >=20 > please see inline. >=20 > Ulrich >=20 > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20 > Sent: Wednesday, October 01, 2014 3:28 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: Re: [Dime] DOIC #70 - Proposed resolution to core issue >=20 > Ulrich, >=20 > Yes, but the proposed resolution for #70 is that a DOIC supporting = agent=20 > strip host overload reports from requests that did not have a=20 > destination-host AVP. > yes that was the original proposal; however during discussion > we came up with a compromise that allows (rather than mandates) the > agent to strip host type OLRs. Steve sent in a separate email that he would be okay saying that an = agent MAY strip the host report. Do I read this comment correctly to = mean that you agree with that? (I would also be okay with a MAY, but = would oppose anything stronger.) From nobody Mon Oct 6 02:33:12 2014 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 DF6371A1B25 for ; Mon, 6 Oct 2014 02:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.387 X-Spam-Level: X-Spam-Status: No, score=-5.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 XIXwKIWoiInt for ; Mon, 6 Oct 2014 02:33:08 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97DFA1A02D1 for ; Mon, 6 Oct 2014 02:33:08 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s969X62c008924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Oct 2014 09:33:06 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s969X3V2000944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Oct 2014 11:33:05 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.218]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0195.001; Mon, 6 Oct 2014 11:33:03 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Ben Campbell Thread-Topic: [Dime] DOIC #70 - Proposed resolution to core issue Thread-Index: AQHP3LzxVwlySCWp3U+Xg2cvYp/Vlpwa49oAgAA4IoCAAUxH0IACWW8AgAQPQjA= Date: Mon, 6 Oct 2014 09:33:03 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668152134CF@DEMUMBX014.nsn-intra.net> References: <542AC192.9090600@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681521304D@DEMUMBX014.nsn-intra.net> <542C0155.7050908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152131BD@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.157] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2074 X-purgate-ID: 151667::1412587986-00001FC1-8EAAF96A/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/geh2nswE82PEFgOAs48ViokUJNY Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC #70 - Proposed resolution to core issue 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, 06 Oct 2014 09:33:11 -0000 Ben, yes, the agent that takes the role of the reporting node for realm reports = MAY strip host reports. This is independent from whether or not the realm i= s actually overloaded (i.e. whether or not a realm report is actually sent)= . Actually I am more concerned with complexity at the client side. Ideally I would like to see a solution where the client (which does not sup= port any extension) is not required to do more than just processing the fir= st OLR within an answer, and may safely ignore additional OLRs. This would = mean that the agent that takes the option not to strip the host report must= insert its realm report (if any) before the host report. I hope that is acceptable. Ulrich -----Original Message----- From: ext Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Friday, October 03, 2014 11:10 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext Steve Donovan; dime@ietf.org Subject: Re: [Dime] DOIC #70 - Proposed resolution to core issue One comment inline. On Oct 2, 2014, at 3:31 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, >=20 > please see inline. >=20 > Ulrich >=20 > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20 > Sent: Wednesday, October 01, 2014 3:28 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: Re: [Dime] DOIC #70 - Proposed resolution to core issue >=20 > Ulrich, >=20 > Yes, but the proposed resolution for #70 is that a DOIC supporting agent= =20 > strip host overload reports from requests that did not have a=20 > destination-host AVP. > yes that was the original proposal; however during discussion > we came up with a compromise that allows (rather than mandates) the > agent to strip host type OLRs. Steve sent in a separate email that he would be okay saying that an agent M= AY strip the host report. Do I read this comment correctly to mean that you= agree with that? (I would also be okay with a MAY, but would oppose anythi= ng stronger.) From nobody Mon Oct 6 17:39:29 2014 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 9F13D1A90E0 for ; Mon, 6 Oct 2014 17:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 VfKnwbj7YP79 for ; Mon, 6 Oct 2014 17:39:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE621A88B4 for ; Mon, 6 Oct 2014 17:39:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNJ29443; Tue, 07 Oct 2014 00:39:21 +0000 (GMT) Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 7 Oct 2014 01:39:20 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.45]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Tue, 7 Oct 2014 08:39:11 +0800 From: "Shishufeng (Susan)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Maria Cruz Bartolome" , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host Thread-Index: AQHP2XX4KWj6QHHCr0yqOWS1GJJJ85wj2Pgf Date: Tue, 7 Oct 2014 00:39:11 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F258DF7CE8F@SZXEMA512-MBX.china.huawei.com> References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> <5409C5A4.5090203@usdonovans.com> <087A34937E64E74E848732CFF8354B920983BD00@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B920983BF65@ESESSMB101.ericsson.se>, <5BCBA1FC2B7F0B4C9D935572D90006681520B965@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520B965@DEMUMBX014.nsn-intra.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.156.197] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dime/TlAFet9RjiPfAvJZt4Z9oKPwKGk Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host 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, 07 Oct 2014 00:39:26 -0000 Dear all, I support Ulrich's interpretation, i.e. a realm report may be used only in = the case the "server" which will finally serve the request is not available= to the client which sends the request.=20 Best Regards, Susan ________________________________________ From: Wiehe, Ulrich (NSN - DE/Munich) [ulrich.wiehe@nsn.com] Sent: 26 September 2014 18:37 To: ext Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ie= tf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Mcruz, JJ, Maybe I missed your point, but my understanding is a bit different. Please see the attached proposal. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Friday, September 26, 2014 11:58 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dime-ov= li@tools.ietf.org Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Dear JJ, all I think I understand your concern. I modified text in clause 6.6 to clarify this point. Attached. Let me know your opinions. Best regards /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com] Sent: viernes, 26 de septiembre de 2014 10:12 To: Maria Cruz Bartolome; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.or= g Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi Maria Cruz 1) The hereafter proposed text is in a sub part of section 6.6 addressing = the overload treatment when the OC-report type indicates realm report so = according to a Realm type OLR. The proposed text mentions "...Origin-Host = AVP of the received message that contained the OC-OLR AVP". This OC-OLR AV= P can be understood as the Realm type OLR subject of this section 6.6 subp= art (this was my first reading), but it is another report which is a host t= ype OLR generated by this peer. As you said we have to distinguish when either a host or a realm report to = be applied, so here the proposal is to exclude from the text the case where= the reacting node has an active type Host type OLR of which the Origin Hos= t match the peer identity, as for this case the host type OLR will be appli= ed. On this basis I would propose write "Host type OC-OLR AVP" as hereafter= . "The Destination-Host AVP is absent in the request and the value of peer id= entity associated with the connection used to send the request does not mat= ch the value of the Origin-Host AVP of a received message that contained a = Host type OC-OLR AVP" 2) When thinking a bit more to this case where the reacting node is directl= y connected to the reporting node (eg a Client directly connected to two or= more servers, without intermediate DA, or a DA acting as a reacting node d= irectly connected to servers). The servers usually only send Host type repo= rts (I know there is a debate on servers sending realm reports), so the r= eacting node will not receive Realm reports. For requests for which there = is no destination Host, the reacting node will select the peer according to= the host OLRs it has or not for each of the peers (eg a peer that is not = overload or with a small overload ) and then apply the abatement/throttlin= g according to the Host type OLR of this peer. I think we have the same und= erstanding. Best regards JJacques -----Message d'origine----- De : Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] Envoy=E9 : jeudi 25 septembre 2014 18:28 =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dime-= ovli@tools.ietf.org Objet : RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, = with absent Destination-Host Dear JJ, I do not understand your point. Proposed clarification has the purpose to allow a reacting node to distingu= ish when either a host or a realm report shall apply. Some time ago we based such a distinction on the presence (meaning host rep= ort) or absence (meaning realm report). Now we have covered the case for host reports when the host is absent but i= t refers to the directly connected peer. Therefore, just absence does not a= llow the reacting node to identify it has to apply a realm report. Let me know if this clarifies, or if I may be missing your point. Thanks /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com] Sent: viernes, 12 de septiembre de 2014 14:13 To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolom= e Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi MCruz The proposed text applies to the realm report. Realm OLRs (in particular with same seq number) may be conveyed in answers = with different Origin-host (but with same Origin realm), so what means to r= efer "to the Origin-Host AVP of the received message that contained the (re= alm type) OC-OLR AVP". This is different from the Host report, where the h= ost type OC-OLR always refers to the origin host of the answer. Can you clarify and give a use case / topology case. Best regards JJacques -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy= =E9 : vendredi 5 septembre 2014 16:16 =C0 : dime@ietf.org; draft-ietf-dime-= ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] [= dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destinat= ion-Host I agree. On 9/5/14, 2:40 AM, dime issue tracker wrote: > #69: Report Type - Realm, with absent Destination-Host > > In clause 6.6, host report was updated to add: > > ... or the Destination-Host is > not present in the request but the value of peer identity > associated with the connection used to send the request matches > the value of the Origin-Host AVP of the received message that > contained the OC-OLR AVP. > > but this clarification needs to be included as well for realm report. > > Original text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request. > > ... > > Proposed text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request and the the val= ue > of peer identity associated with the connection used to send the reques= t > does not match the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime= From nobody Thu Oct 9 05:03:12 2014 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 C0DB51ACDF7 for ; Thu, 9 Oct 2014 05:03:09 -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 5DHkFwmqABUI for ; Thu, 9 Oct 2014 05:03:07 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DDF61ACDEF for ; Thu, 9 Oct 2014 05:03:07 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id 10so979029lbg.18 for ; Thu, 09 Oct 2014 05:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zhY9Ro1RSao/N3tq+ndIBhFUg196O7p1xEIZ0BIv2+8=; b=NMlhOw/gZ9JWo4DRxhWgrbpaZgBrn/QxUGi/ReLmKcqjS4roP2CgURg03y02DnfIlQ gaw/2D3kBa9AfkZLNBcdMvHllwLX337TiqwgcU9Yy0YJXRVnAT+xSZfPNOMRrH4eKuWQ Iu3KykohJ46nvbhkCym7GEKwtm2HdTlhINIGH44uFShtKEyv7HEwpVU5DqcbVOo4nLSc ct3T1da250TcozdJwsOKqZ7aFk1pPR/DTFecBtwrdesO0GRRtyYEX6IxDYUhyuhrRJuu RBHSoAo5IIox5+fsRPWHkPqawFrBXcqaHwgLRKP/3eGbIWGqBshhR7YyhT/GUWGaJ8Gl vljg== X-Received: by 10.112.190.69 with SMTP id go5mr17574918lbc.32.1412856183539; Thu, 09 Oct 2014 05:03:03 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id pm3sm915081lbb.15.2014.10.09.05.03.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Oct 2014 05:03:02 -0700 (PDT) Message-ID: <5436797C.7020606@gmail.com> Date: Thu, 09 Oct 2014 15:03:08 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/nKikgFY6zmRuyqt8VA5_56QdyXs Subject: [Dime] Honolulu agenda building.. 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, 09 Oct 2014 12:03:10 -0000 Folks, IETF 91 is getting close.. we have again asked for 2.5h slot. We have the obvious agenda topics like WG update and DOIC. If you wish to present something or even propose new work, please send the chairs a request. - Jouni & Lionel From nobody Thu Oct 9 08:18:11 2014 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 A907C1A6EE1 for ; Thu, 9 Oct 2014 08:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 dZvgRz0AdDoa for ; Thu, 9 Oct 2014 08:18:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 69C911A1AFE for ; Thu, 9 Oct 2014 08:18:06 -0700 (PDT) Received: from localhost ([::1]:47313 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XcFTd-0002J9-2y; Thu, 09 Oct 2014 08:18:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Thu, 09 Oct 2014 15:18:00 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/74 Message-ID: <066.528fadde671b27f69242e310aaface81@trac.tools.ietf.org> X-Trac-Ticket-ID: 74 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3za-llWzfcEMwLjVOYu-0HtQukY Cc: dime@ietf.org Subject: [Dime] [dime] #74 (draft-ietf-dime-ovli): Move section 3.7. Considerations for Applications Integrating the DOIC Solution to Appendix X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 15:18:09 -0000 #74: Move section 3.7. Considerations for Applications Integrating the DOIC Solution to Appendix Proposal to move this section to an Appendix. It provides good information but having it as part of section 3 decreases the readability of the document. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Thu Oct 9 08:48:44 2014 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 B684E1ACFE7 for ; Thu, 9 Oct 2014 08:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.88 X-Spam-Level: *** X-Spam-Status: No, score=3.88 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_LIST=2.3, SPF_NEUTRAL=0.779, WEIRD_PORT=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 HO0ieD_446Ox for ; Thu, 9 Oct 2014 08:27:03 -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 E52781ACFAD for ; Thu, 9 Oct 2014 08:27:02 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62224 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XcFcJ-0002PO-QP for dime@ietf.org; Thu, 09 Oct 2014 08:27:01 -0700 Message-ID: <5436A942.1010400@usdonovans.com> Date: Thu, 09 Oct 2014 10:26:58 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------060503040209050300020606" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Yo6QgpI4ER-zQREOrcfChMWlOcc X-Mailman-Approved-At: Thu, 09 Oct 2014 08:48:40 -0700 Subject: [Dime] Prep for next weeks DIME interim meeting 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, 09 Oct 2014 15:27:34 -0000 This is a multi-part message in MIME format. --------------060503040209050300020606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, As we prepare for next weeks interim meeting, please remember to use the following as the source document: https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-04.txt I've attached a copy for everyone's convenience. Regards, Steve --------------060503040209050300020606 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-dime-ovli-04.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="draft-ietf-dime-ovli-04.txt" draft-docdt-dime-ovli/draft-ietf-dime-ovli-04.txt at master · jounikor/draft-docdt-dime-ovli · GitHub Skip to content

/draft-docdt-dime-ovli

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Clone in Desktop Download ZIP
branch: master
draft-docdt-dime-ovli / draft-ietf-dime-ovli-04.txt
Fetching contributors…

Cannot retrieve contributors at this time

2465 lines (1744 sloc) 106.4 kb
Raw Blame History
Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed.
Internet-Draft Broadcom
Intended status: Standards Track S. Donovan, Ed.
Expires: March 9, 2015 B. Campbell
Oracle
L. Morand
Orange Labs
September 5, 2014
Diameter Overload Indication Conveyance
draft-ietf-dime-ovli-04.txt
Abstract
This specification documents a Diameter Overload Control (DOC) base
solution and the dissemination of the overload report information.
Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 9, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Korhonen, et al. Expires March 9, 2015 [Page 1]
Internet-Draft DOIC September 2014
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Piggybacking Principle (Non normative) . . . . . . . . . 6
3.2. DOIC Capability Announcement (Non normative) . . . . . . 7
3.3. DOIC Overload Condition Reporting (Non normative) . . . . 9
3.4. DOIC Extensibility (Non normative) . . . . . . . . . . . 10
3.5. Simplified Example Architecture (Non normative) . . . . . 10
3.6. Considerations for Applications Integrating the DOIC
Solution (Non normative) . . . . . . . . . . . . . . . . 11
3.6.1. Application Classification (Non normative) . . . . . 11
3.6.2. Application Type Overload Implications (Non
normative) . . . . . . . . . . . . . . . . . . . . . 12
3.6.3. Request Transaction Classification (Non normative) . 14
3.6.4. Request Type Overload Implications (Non normative) . 14
4. Solution Procedures (Normative) . . . . . . . . . . . . . . . 16
4.1. Capability Announcement (Normative) . . . . . . . . . . . 16
4.1.1. Reacting Node Behavior (Normative) . . . . . . . . . 16
4.1.2. Reporting Node Behavior (Normative) . . . . . . . . 17
4.1.3. Agent Behavior (Normative) . . . . . . . . . . . . . 18
4.2. Overload Report Processing (Normative) . . . . . . . . . 18
4.2.1. Overload Control State (Normative) . . . . . . . . . 18
4.2.2. Reacting Node Behavior (Normative) . . . . . . . . . 20
4.2.3. Reporting Node Behavior (Normative) . . . . . . . . 22
4.2.4. Agent Behavior (Normative) . . . . . . . . . . . . . 22
4.3. Protocol Extensibility (Normative) . . . . . . . . . . . 23
5. Loss Algorithm (Normative) . . . . . . . . . . . . . . . . . 24
5.1. Overview (Non normative) . . . . . . . . . . . . . . . . 24
5.2. Use of OC-Reduction-Percentage AVP . . . . . . . . . . . 25
5.3. Reporting Node Behavior (Normative) . . . . . . . . . . . 25
5.4. Reacting Node Behavior (Normative) . . . . . . . . . . . 25
6. Attribute Value Pairs (Normative) . . . . . . . . . . . . . . 26
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 27
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 27
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 28
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 29
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 29
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 30
Korhonen, et al. Expires March 9, 2015 [Page 2]
Internet-Draft DOIC September 2014
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 31
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 31
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 32
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 33
9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 33
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 34
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 35
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 35
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Issues left for future specifications . . . . . . . 37
A.1. Additional traffic abatement algorithms . . . . . . . . . 37
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 37
A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 38
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 38
B.1. Mix of Destination-Realm routed requests and Destination-
Host routed requests . . . . . . . . . . . . . . . . . . 38
Appendix C. Restructuring of -02 version of the draft . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction
This specification defines a base solution for Diameter Overload
Control (DOC), refered to as Diameter Overload Indication Conveyance
(DOIC). The requirements for the solution are described and
discussed in the corresponding design requirements document
[RFC7068]. Note that the overload control solution defined in this
specification does not address all the requirements listed in
[RFC7068]. A number of overload control related features are left
for the future specifications.
The solution defined in this specification addresses Diameter
overload control between Diameter nodes that support the DOIC
solution. Furthermore, the solution is designed to apply to existing
and future Diameter applications, requires no changes to the Diameter
base protocol [RFC6733] and is deployable in environments where some
Diameter nodes do not implement the Diameter overload control
solution defined in this specification.
Korhonen, et al. Expires March 9, 2015 [Page 3]
Internet-Draft DOIC September 2014
2. Terminology and Abbreviations
Abatement Algorithm
An algorithm requested by reporting nodes and used by reacting
nodes to reduce the amount of traffic sent during an occurrence of
overload control.
Throttling
Throttling is the reduction of the number of requests sent to an
entity. Throttling can include a client dropping requests, or an
agent rejecting requests with appropriate error responses.
Clients and agents can also choose to redirect throttled requests
to some other entity or entities capable of handling them.
Editor's note: Propose to add a definition of Abatement to include
both throttling and diversion (redirecting of messages) actions.
Then to modify this definition to include just the rejecting of
requests and adding a definition of diversion.
Reporting Node
A Diameter node that generates an overload report. (This may or
may not be the overloaded node.)
Reacting Node
A Diameter node that consumes and acts upon a report. Note that
"act upon" does not necessarily mean the reacting node applies an
abatement algorithm; it might decide to delegate that downstream,
in which case it also becomes a "reporting node".
Overload Control State (OCS)
State describing an occurrence of overload control maintained by
reporting and reacting nodes.
Overload Report (OLR)
A set of AVPs sent by a reporting node indicating the start or
continuation of an occurrence of overload control.
3. Solution Overview
The Diameter Overload Information Conveyance (DOIC) mechanism allows
Diameter nodes to request other nodes to perform overload abatement
Korhonen, et al. Expires March 9, 2015 [Page 4]
Internet-Draft DOIC September 2014
actions, that is, actions to reduce the load offered to the
overloaded node or realm.
A Diameter node that supports DOIC is known as a "DOIC node". Any
Diameter node can act as a DOIC node, including clients, servers, and
agents. DOIC nodes are further divided into "Reporting Nodes" and
"Reacting Nodes." A reporting node requests overload abatement by
sending an Overload Report (OLR) to one or more reacting nodes.
A reacting node consumes OLRs, and performs whatever actions are
needed to fulfill the abatement requests included in the OLRs. A
Reporting node may report overload on its own behalf, or on behalf of
other (typically upstream) nodes. Likewise, a reacting node may
perform overload abatement on its own behalf, or on behalf of other
(typically downstream) nodes.
A node's role as a DOIC node is independent of its Diameter role.
For example, Diameter relay and proxy agents may act as DOIC nodes,
even though they are not endpoints in the Diameter sense. Since
Diameter enables bi-directional applications, where Diameter servers
can send requests towards Diameter clients, a given Diameter node can
simultaneously act as a reporting node and a reacting node.
Likewise, a relay or proxy agent may act as a reacting node from the
perspective of upstream nodes, and a reporting node from the
perspective of downstream nodes.
DOIC nodes do not generate new messages to carry DOIC related
information. Rather, they "piggyback" DOIC information over existing
Diameter messages by inserting new AVPs into existing Diameter
requests and responses. Nodes indicate support for DOIC, and any
needed DOIC parameters by inserting an OC_Supported_Features AVP
(Section 6.2) into existing requests and responses. Reporting nodes
send OLRs by inserting OC-OLR AVPs (Section 6.3).
A given OLR applies to the Diameter realm and application of the
Diameter message that carries it. If a reporting node supports more
than one realm and/or application, it reports independently for each
combination of realm and application. Similarly, OC-Feature-Vector
AVPs apply to the realm and application of the enclosing message.
This implies that a node may support DOIC for one application and/or
realm, but not another, and may indicate different DOIC parameters
for each application and realm for which it supports DOIC.
Reacting nodes perform overload abatement according to an agreed-upon
abatement algorithm. An abatement algorithm defines the meaning of
the parameters of an OLR, and the procedures required for overload
abatement. This document specifies a single must-support algorithm,
Korhonen, et al. Expires March 9, 2015 [Page 5]
Internet-Draft DOIC September 2014
namely the "loss" algorithm Section 5). Future specifications may
introduce new algorithms.
Overload conditions may vary in scope. For example, a single
Diameter node may be overloaded, in which case reacting nodes may
reasonably attempt to send throttled requests to other destinations
or via other agents. On the other hand, an entire Diameter realm may
be overloaded, in which case such attempts would do harm. DOIC OLRs
have a concept of "report type" (Section 6.6), where the type defines
such behaviors. Report types are extensible. This document defines
report types for overload of a specific server, and for overload of
an entire realm.
A report of type host is sent to indicate the overload of a specific
server for the application-id indicated in the transaction. When
receiving an OLR of type host, a reacting node applies overload
abatement to what is referred to in this document as host-routed
requests. This is the set of requests that the reacting node knows
will be served by a particular host, either due to the presence of a
Destination-Host AVP, or by some other local knowledge on the part of
the reacting node. The reacting node applies overload abatement on
those host-routed requests which the reacting node knows will be
served by the server that matches the Origin-Host AVP of the received
message that contained the received OLR of type host.
A report type of realm is sent to indicate the overload of all
servers in a realm for the application-id. When receiving an OLR of
type realm, a reacting node applies overload abatement to what is
referred to in this document as realm-routed requests. This is the
set of requests that are not host-routed as defined in the previous
paragraph.
While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
that are "adjacent" for DOIC purposes may not be adjacent from a
Diameter, or transport, perspective. For example, one or more
Diameter agents that do not support DOIC may exist between a given
pair of reporting and reacting nodes, as long as those agents pass
unknown AVPs through unmolested. The report types described in this
document can safely pass through non-supporting agents. This may not
be true for report types defined in future specifications. Documents
that introduce new report types MUST describe any limitations on
their use across non-supporting agents.
3.1. Piggybacking Principle (Non normative)
The overload control AVPs defined in this specification have been
designed to be piggybacked on top of existing application message
exchanges. This is made possible by adding overload control top
Korhonen, et al. Expires March 9, 2015 [Page 6]
Internet-Draft DOIC September 2014
level AVPs, the OC-OLR AVP and the OC-Supported-Features AVP as
optional AVPs into existing commands when the corresponding Command
Code Format (CCF) specification allows adding new optional AVPs (see
Section 1.3.4 of [RFC6733]).
Reacting nodes indicate support for DOIC by including the OC-
Supported-Features AVP all request messages originated or relayed by
the Diameter node.
Reporting nodes indicate support for DOIC by including the OC-
Supported-Features AVP in all answer messages originated or relayed
by the Diameter node. Reporting nodes also include overload reports
using the OC-OLR AVP in answer messages.
Note: There is no new Diameter application defined to carry
overload related AVPs. The DOIC AVPs are carried in existing
Diameter application messages.
Note that the overload control solution does not have fixed server
and client roles. The DOIC node role is determined based on the
message type: whether the message is a request (i.e. sent by a
"reacting node") or an answer (i.e. send by a "reporting node").
Therefore, in a typical "client-server" deployment, the "client" MAY
report its overload condition to the "server" for any server
initiated message exchange. An example of such is the server
requesting a re-authentication from a client.
3.2. DOIC Capability Announcement (Non normative)
The DOIC solutions supports the ability for Diameter nodes to
determine if other nodes in the path of a request support the
solution. This capability is refered to as DOIC Capability
Announcement (DCA) and is separate from Diameter Capability Exchange.
The DCA mechanism is built around the piggybacking principle used for
transporting Diameter overload AVPs. This includes both DCA AVPs and
AVPs associated with Diameter overload reports. This allows for the
DCA AVPs to be carried across Diameter nodes that do not support the
DOIC solution.
The DCA mechanism uses the OC-Supported-Features AVPs to indicate the
Diameter overload features supported.
The first node in the path of a Diameter request that supports the
DOIC solution inserts the OC-Supported-Feature AVP in the request
message. This includes an indication that it supports the loss
overload abatement algorithm defined in this specification (see
Section 5). This insures that there is at least one commonly
Korhonen, et al. Expires March 9, 2015 [Page 7]
Internet-Draft DOIC September 2014
supported overload abatement algorithm between the reporting node and
the reacting nodes in the path of the request.
DOIC must support deployments where Diameter Clients and/or
Diameter servers do not support the DOIC solution. In this
scenario, it is assumed that Diameter Agents that support the DOIC
solution will handle overload abatement for the non supporting
clients. In this case the DOIC agent will insert the OC-
Supporting-Features AVP in requests that do not already contain
one, telling the reporting node that there is a DOIC node that
will handle overload abatement.
The reporting node inserts the OC-Supported-Feature AVP in all answer
messages to requests that contained the OC-Supported-Feature AVP.
The contents of the reporting node's OC-Supported-Feature AVP
indicate the set of Diameter overload features supported by the
reporting node with one exception.
The reporting node only includes an indication of support for one
overload abatement algorithm. This is the algorithm that the
reporting node intends to use should it enter an overload condition.
Reacting nodes can use the indicated overload abatement algorithm to
prepare for possible overload reports.
Note that the loss algorithm defined in this document is a
stateless abatement algorithm. As a result it does not require
any actions by reacting nodes prior to the receipt of an overload
report. Stateful abatement algorithms that base the abatement
logic on a history of request messages sent might require reacting
nodes to maintain state to insure that overload reports can be
properly handled.
The individual features supported by the DOIC nodes are indicated in
the OC-Feature-Vector AVP. Any semantics associated with the
features will be defined in extension specifications that introduce
the features.
The DCA mechanism must also support the scenario where the set of
features supported by the sender of a request and by agents in the
path of a request differ. In this case, the agent updates the OC-
Supported-Feature AVP to reflect the mixture of the two sets of
supported features.
The logic to determine the content of the modified OC-Supported-
Feature AVP is out-of-scope for this specification and is left to
implementation decisions. Care must be taken in doing so not to
introduce interoperability issues for downstream or upstream DOIC
nodes.
Korhonen, et al. Expires March 9, 2015 [Page 8]
Internet-Draft DOIC September 2014
3.3. DOIC Overload Condition Reporting (Non normative)
As with DOIC Capability Announcement, Overload Condition Reporting
uses new AVPs (Section 6.3) to indicate an overload condition.
The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP
includes the type of report, an overload report ID, the length of
time that the report is valid and abatement algorithm specific AVPs.
Two types of overload reports are defined in this document, host
reports and realm reports.
Host reports apply to traffic that is sent to a specific Diameter
host. The applies to requests that contain the Destination-Host AVP
that contains a DiameterIdentity that matches that of the overload
report. These requests are referred to as host-routed requests. A
host report also applies to realm-routed requests, requests that do
not have a Destination-Host AVP, when the selected route for the
request is a connection to the impacted host.
Realm reports apply to realm-routed requests for a specific realm as
indicated in the Destination-Realm AVP.
Reporting nodes are responsible for determining the need for a
reduction of traffic. The method for making this determination is
implementation specific and depend on the type of overload report
being generated. A host report, for instance, will generally be
generated by tracking utilization of resources required by the host
to handle transactions for the the Diameter application. A realm
report will generally impact the traffic sent to multiple hosts and,
as such, will typically require tracking the capacity of the servers
able to handle realm-routed requests for the application.
Once a reporting node determines the need for a reduction in traffic,
it uses the DOIC defined AVPs to report on the condition. These AVPs
are included in answer messages sent or relayed by the reporting
node. The reporting node indicates the overload abatement algorithm
that is to be used to handle the traffic reduction in the OC-
Supported-Features AVP. The OC-OLR AVP is used to communicate
information about the requested reduction.
Reacting nodes, upon receipt of an overload report, are responsible
for applying the abatement algorithm to traffic impacted by the
overload report. The method used for that abatement is dependent on
the abatement algorithm. The loss abatement algorithm is defined in
this document (Section 5). Other abatement algorithms can be defined
in extensions to the DOIC solutions.
Korhonen, et al. Expires March 9, 2015 [Page 9]
Internet-Draft DOIC September 2014
As the conditions that lead to the generation of the overload report
change the reporting node can send new overload reports requesting
greater reduction if the condition gets worse or less reduction if
the condition improves. The reporting node sends an overload report
with a duration of zero to indicate that the overlaod condition has
ended and use of the abatement algorithm is no longer needed.
The reacting node also determines when the overload report expires
based on the OC-Validaty-Duration AVP in the overload report and
stops applying the abatement algorithm when the report expires.
3.4. DOIC Extensibility (Non normative)
The DOIC solutions is designed to be extensible. This extensibility
is based on existing Diameter based extensibility mechanisms.
There are multiple categories of extensions that are expected. This
includes the definition of new overload abatement algorithms, the
definition of new report types and new definitions of the scope of
messages impacted by an overload report.
The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes
to communicate supported features. The specific features supported
by the DOIC node are indicated in the OC-Feature-Vector AVP. DOIC
extensions must define new values for the OC-Feature-Vector AVP.
DOIC extensions also have the ability to add new AVPs to the OC-
Supported-Features AVP, if additional information about the new
feature is required to be communicate.
Overload abatement algorithms use the OC-OLR AVP to communicate
overload occurances. This AVP can also be extended to add new AVPs
allowing a reporting nodes to communicate additional information
about handling an overload condition.
If necessary, new extensions can also define new top level AVPs. It
is, however, recommended that DOIC extensions use the OC-Supported-
Features and OC-OLR to carry all DOIC related AVPs.
3.5. Simplified Example Architecture (Non normative)
Figure 1 illustrates the simplified architecture for Diameter
overload information conveyance.
Korhonen, et al. Expires March 9, 2015 [Page 10]
Internet-Draft DOIC September 2014
Realm X Same or other Realms
<--------------------------------------> <---------------------->
+--^-----+ : (optional) :
|Diameter| : :
|Server A|--+ .--. : +---^----+ : .--.
+--------+ | _( `. : |Diameter| : _( `. +---^----+
+--( )--:-| Agent |-:--( )--|Diameter|
+--------+ | ( ` . ) ) : +-----^--+ : ( ` . ) ) | Client |
|Diameter|--+ `--(___.-' : : `--(___.-' +-----^--+
|Server B| : :
+---^----+ : :
End-to-end Overload Indication
1) <----------------------------------------------->
Diameter Application Y
Overload Indication A Overload Indication A'
2) <----------------------> <---------------------->
standard base protocol standard base protocol
Figure 1: Simplified architecture choices for overload indication
delivery
In Figure 1, the Diameter overload indication can be conveyed (1)
end-to-end between servers and clients or (2) between servers and
Diameter agent inside the realm and then between the Diameter agent
and the clients when the Diameter agent acting as back-to-back-agent
for DOIC purposes.
3.6. Considerations for Applications Integrating the DOIC Solution (Non
normative)
THis section outlines considerations to be taken into account when
integrating the DOIC solution into Diameter applications.
3.6.1. Application Classification (Non normative)
The following is a classification of Diameter applications and
requests. This discussion is meant to document factors that play
into decisions made by the Diameter identity responsible for handling
overload reports.
Section 8.1 of [RFC6733] defines two state machines that imply two
types of applications, session-less and session-based applications.
Korhonen, et al. Expires March 9, 2015 [Page 11]
Internet-Draft DOIC September 2014
The primary difference between these types of applications is the
lifetime of Session-Ids.
For session-based applications, the Session-Id is used to tie
multiple requests into a single session.
In session-less applications, the lifetime of the Session-Id is a
single Diameter transaction, i.e. the session is implicitly
terminated after a single Diameter transaction and a new Session-Id
is generated for each Diameter request.
For the purposes of this discussion, session-less applications are
further divided into two types of applications:
Stateless applications:
Requests within a stateless application have no relationship to
each other. The 3GPP defined S13 application is an example of a
stateless application [S13], --> where only a Diameter command is
defined between a client and a server and no state is maintained
between two consecutive transactions.
Pseudo-session applications:
Applications that do not rely on the Session-Id AVP for
correlation of application messages related to the same session
but use other session-related information in the Diameter requests
for this purpose. The 3GPP defined Cx application [Cx] is an
example of a pseudo-session application.
The Credit-Control application defined in [RFC4006] is an example of
a Diameter session-based application.
The handling of overload reports must take the type of application
into consideration, as discussed in Section 3.6.2.
3.6.2. Application Type Overload Implications (Non normative)
This section discusses considerations for mitigating overload
reported by a Diameter entity. This discussion focuses on the type
of application. Section 3.6.3 discusses considerations for handling
various request types when the target server is known to be in an
overloaded state.
These discussions assume that the strategy for mitigating the
reported overload is to reduce the overall workload sent to the
overloaded entity. The concept of applying overload treatment to
requests targeted for an overloaded Diameter entity is inherent to
Korhonen, et al. Expires March 9, 2015 [Page 12]
Internet-Draft DOIC September 2014
this discussion. The method used to reduce offered load is not
specified here but could include routing requests to another Diameter
entity known to be able to handle them, or it could mean rejecting
certain requests. For a Diameter agent, rejecting requests will
usually mean generating appropriate Diameter error responses. For a
Diameter client, rejecting requests will depend upon the application.
For example, it could mean giving an indication to the entity
requesting the Diameter service that the network is busy and to try
again later.
Stateless applications:
By definition there is no relationship between individual requests
in a stateless application. As a result, when a request is sent
or relayed to an overloaded Diameter entity - either a Diameter
Server or a Diameter Agent - the sending or relaying entity can
choose to apply the overload treatment to any request targeted for
the overloaded entity.
Pseudo-session applications:
For pseudo-session applications, there is an implied ordering of
requests. As a result, decisions about which requests towards an
overloaded entity to reject could take the command code of the
request into consideration. This generally means that
transactions later in the sequence of transactions should be given
more favorable treatment than messages earlier in the sequence.
This is because more work has already been done by the Diameter
network for those transactions that occur later in the sequence.
Rejecting them could result in increasing the load on the network
as the transactions earlier in the sequence might also need to be
repeated.
Session-based applications:
Overload handling for session-based applications must take into
consideration the work load associated with setting up and
maintaining a session. As such, the entity sending requests
towards an overloaded Diameter entity for a session-based
application might tend to reject new session requests prior to
rejecting intra-session requests. In addition, session ending
requests might be given a lower probability of being rejected as
rejecting session ending requests could result in session status
being out of sync between the Diameter clients and servers.
Application designers that would decide to reject mid-session
requests will need to consider whether the rejection invalidates
the session and any resulting session clean-up procedures.
Korhonen, et al. Expires March 9, 2015 [Page 13]
Internet-Draft DOIC September 2014
3.6.3. Request Transaction Classification (Non normative)
Independent Request:
An independent request is not correlated to any other requests
and, as such, the lifetime of the session-id is constrained to an
individual transaction.
Session-Initiating Request:
A session-initiating request is the initial message that
establishes a Diameter session. The ACR message defined in
[RFC6733] is an example of a session-initiating request.
Correlated Session-Initiating Request:
There are cases when multiple session-initiated requests must be
correlated and managed by the same Diameter server. It is notably
the case in the 3GPP PCC architecture [PCC], where multiple
apparently independent Diameter application sessions are actually
correlated and must be handled by the same Diameter server.
Intra-Session Request:
An intra session request is a request that uses the same Session-
Id than the one used in a previous request. An intra session
request generally needs to be delivered to the server that handled
the session creating request for the session. The STR message
defined in [RFC6733] is an example of an intra-session requests.
Pseudo-Session Requests:
Pseudo-session requests are independent requests and do not use
the same Session-Id but are correlated by other session-related
information contained in the request. There exists Diameter
applications that define an expected ordering of transactions.
This sequencing of independent transactions results in a pseudo
session. The AIR, MAR and SAR requests in the 3GPP defined Cx
[Cx] application are examples of pseudo-session requests.
3.6.4. Request Type Overload Implications (Non normative)
The request classes identified in Section 3.6.3 have implications on
decisions about which requests should be throttled first. The
following list of request treatment regarding throttling is provided
as guidelines for application designers when implementing the
Diameter overload control mechanism described in this document. The
Korhonen, et al. Expires March 9, 2015 [Page 14]
Internet-Draft DOIC September 2014
exact behavior regarding throttling is a matter of local policy,
unless specifically defined for the application.
Independent requests:
Independent requests can be given equal treatment when making
throttling decisions.
Session-initiating requests:
Session-initiating requests represent more work than independent
or intra-session requests. Moreover, session-initiating requests
are typically followed by other session-related requests. As
such, as the main objective of the overload control is to reduce
the total number of requests sent to the overloaded entity,
throttling decisions might favor allowing intra-session requests
over session-initiating requests. Individual session-initiating
requests can be given equal treatment when making throttling
decisions.
Correlated session-initiating requests:
A Request that results in a new binding, where the binding is used
for routing of subsequent session-initiating requests to the same
server, represents more work load than other requests. As such,
these requests might be throttled more frequently than other
request types.
Pseudo-session requests:
Throttling decisions for pseudo-session requests can take into
consideration where individual requests fit into the overall
sequence of requests within the pseudo session. Requests that are
earlier in the sequence might be throttled more aggressively than
requests that occur later in the sequence.
Intra-session requests
There are two classes of intra-sessions requests. The first class
consists of requests that terminate a session. The second one
contains the set of requests that are used by the Diameter client
and server to maintain the ongoing session state. Session
terminating requests should be throttled less aggressively in
order to gracefully terminate sessions, allow clean-up of the
related resources (e.g. session state) and get rid of the need for
other intra-session requests, reducing the session management
impact on the overloaded entity. The default handling of other
intra-session requests might be to treat them equally when making
Korhonen, et al. Expires March 9, 2015 [Page 15]
Internet-Draft DOIC September 2014
throttling decisions. There might also be application level
considerations whether some request types are favored over others.
4. Solution Procedures (Normative)
This section outlines the normative behavior associated with the DOIC
solution.
4.1. Capability Announcement (Normative)
This section defines DOIC Capability Announcement (DCA) behavior.
The DCA procedures are used to indicate support for DOIC and support
for DOIC features. The DOIC features include overload abatement
algorithms supported. It might also include new report types or
other extensions documented in the future.
Diameter nodes indicate support for DOIC by including the OC-
Supported-Features AVP in messages sent or handled by the node.
Diameter agents that support DOIC MUST ensure that all messages have
the OC-Supporting-Features AVP. If a message handled by the DOIC
agent does not include the OC-Supported-Features AVP then the DOIC
agent inserts the AVP. If the message already has the AVP then the
agent either leaves it unchanged in the relayed message or modifies
it to reflect a mixed set of DOIC features.
4.1.1. Reacting Node Behavior (Normative)
A reacting node MUST include the OC-Supported-Features AVP in all
request messages.
A reacting node MUST include the OC-Feature-Vector AVP with an
indication of the loss algorithm.
A reacting node SHOULD indicate support for all other DOIC features
it supports.
An OC-Supported-Features AVP in answer messages indicates there is a
reporting node for the transaction. The reacting node MAY take
action based on the features indicated in the OC-Feature-Vector AVP.
Note that the loss abatement algorithm is the only feature
described in this document and it does not require action to be
taken by the reacting node except when the answer message also has
an overload report. This behavior is described in Section 4.2 and
Section 5.
Korhonen, et al. Expires March 9, 2015 [Page 16]
Internet-Draft DOIC September 2014
4.1.2. Reporting Node Behavior (Normative)
Upon receipt of a request message, a reporting node determines if
there is a reacting node for the transaction based on the presence of
the OC-Supported-Features AVP.
Based on the content of the OC-Supported-Features AVP in the request
message, the reporting node knows what overload control functionality
supported by reacting node(s). The reporting node then acts
accordingly for the subsequent answer messages it initiates.
If the reqeust message contains an OC-Supported-Features AVP then the
reporting node MUST include the OC-Supported-Features AVP in the
answer message for that transaction.
The reporting node MUST indicate support for one and only one
abatement algorithm in the OC-Feature-Vector AVP. The abatement
algorithm included MUST be from the set of abatement algorithms
contained in the request messages OC-Supported-Features AVP. The
abatement algorithm included indicates the abatement algorithm the
reporting node wants the reacting node to use when the reporting node
enters an overload condition.
The reporting node MUST NOT change the selected algorithm during a
period of time that it is in an overload condition and, as a result,
is sending OC-OLR AVPs in answer messages.
The reporting node SHOULD indicate support for other DOIC features it
supports and that apply to the transaction.
Note that not all DOIC features will apply to all Diameter
applications or deployment scenarios. The features included in
the OC-Feature-Vector AVP is based on local reporting node policy.
The reporting node MUST NOT include the OC-Supported-Features AVP,
OC-OLR AVP or any other overload control AVPs defined in extension
drafts in response messages for transactions where the request
message does not include the OC-Supported-Features AVP. Lack of the
OC-Supported-Features AVP in the request message indicates that there
is no reacting node for the transaction.
An agent MAY modify the OC-Supported-Features AVP carried in answer
messages.
Korhonen, et al. Expires March 9, 2015 [Page 17]
Internet-Draft DOIC September 2014
4.1.3. Agent Behavior (Normative)
Editor's note -- Need to add this section.
4.2. Overload Report Processing (Normative)
4.2.1. Overload Control State (Normative)
Both reacting and reporting nodes maintain an overload control state
(OCS) for active overload reports.
4.2.1.1. Overload Control State for Reacting Nodes
A reacting node maintains the following OCS per supported Diameter
application:
o A host-type Overload Control State for each Destination-Host
towards which it sends host-type requests and
o A realm-type Overload Control State for each Destination-Realm
towards which it sends realm-type requests.
A host-type Overload Control State may be identified by the pair of
Application-Id and Destination-Host. A realm-type Overload Control
State may be identified by the pair of Application-Id and
Destination-Realm. The host-type/realm-type Overload Control State
for a given pair of Application and Destination-Host / Destination-
Realm could include the following information:
o Sequence number (as received in OC-OLR)
o Time of expiry (deviated from validity duration as received in OC-
OLR and time of reception)
o Selected Abatement Algorithm (as received in OC-Supported-
Features)
o Algorithm specific input data (as received within OC-OLR, e.g.
Reduction Percentage for Loss)
4.2.1.2. Overload Control States for Reporting Nodes
A reporting node maintains per supported Diameter application and per
supported (and eventually selected) Abatement Algorithm an Overload
Control State.
An Overload Control State may be identified by the pair of
Application-Id and supported Abatement Algorithm.
Korhonen, et al. Expires March 9, 2015 [Page 18]
Internet-Draft DOIC September 2014
The Overload Control State for a given pair of Application and
Abatement Algorithm could include the information:
o Sequence number
o Validity Duration and Expiry Time
o Algorithm specific input data (e.g. Reduction Percentage for
Loss)
Overload Control States for reporting nodes containing a validity
duration of 0 sec. should not expire before any previously sent
(stale) OLR has timed out at any reacting node.
Editor's note: This statement is unclear and contradictory with other
statements. A validity timer of zero seconds indicates that the
overload condition has ended and abatement is no longer requested.
4.2.1.3. Maintaining Overload Control State
Reacting nodes create a host-type OCS identified by OCS-Id = (app-
id,host-id) when receiving an answer message of application app-id
containing an Orig-Host of host-id and a host-type OC-OLR AVP unless
such host-type OCS already exists.
Reacting nodes create a realm-type OCS identified by OCS-Id = (app-
id,realm-id) when receiving an answer message of application app-id
containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP
unless such realm type OCS already exists.
Reacting nodes delete an OCS when it expires (i.e. when current time
minus reception time is greater than validity duration).
Editor's note: Reacting nodes also delete on OCS with an updated OLR
is received with a validity duration of zero.
Reacting nodes update the host-type OCS identified by OCS-Id = (app-
id,host-id) when receiving an answer message of application app-id
containing an Orig-Host of host-id and a host-type OC-OLR AVP with a
sequence number higher than the stored sequence number.
Reacting nodes update the realm-type OCS identified by OCS-Id = (app-
id,realm-id) when receiving an answer message of application app-id
containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP with
a sequence number higher than the stored sequence number.
Korhonen, et al. Expires March 9, 2015 [Page 19]
Internet-Draft DOIC September 2014
Reacting nodes do not delete an OCS when receiving an answer message
that does not contain an OC-OLR AVP (i.e. absence of OLR means "no
change").
Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg)
when receiving a request of application app-id containing an OC-
Supported-Features AVP indicating support of the Abatement Algorithm
Alg (which the reporting node selects) while being overloaded, unless
such OCS already exists.
Reporting nodes delete an OCS when it expires.
Editor's note: Reporting nodes should send updated overload reports
with a validity duration of zero for a period of time after an OCS
expires or is removed due to the overload condition ending.
Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg)
when they detect the need to modify the requested amount of
application app-id traffic reduction.
4.2.2. Reacting Node Behavior (Normative)
Once a reacting node receives an OC-OLR AVP from a reporting node, it
applies traffic abatement based on the selected algorithm with the
reporting node and the current overload condition. The reacting node
learns the reporting node supported abatement algorithms directly
from the received answer message containing the OC-Supported-Features
AVP.
The received OC-Supported-Features AVP does not change the existing
overload condition and/or traffic abatement algorithm settings if the
OC-Sequence-Number AVP contains a value that is equal to the
previously received/recorded value. If the OC-Supported-Features AVP
is received for the first time for the reporting node or the OC-
Sequence-Number AVP value is less than the previously received/
recorded value (and is outside the valid overflow window), then the
sequence number is stale (e.g. an intentional or unintentional
replay) and SHOULD be silently discarded.
As described in Section 6.3, the OC-OLR AVP contains the necessary
information for the overload condition on the reporting node.
From the OC-Report-Type AVP contained in the OC-OLR AVP, the reacting
node learns whether the overload condition report concerns a specific
host (as identified by the Origin-Host AVP of the answer message
containing the OC-OLR AVP) or the entire realm (as identified by the
Origin-Realm AVP of the answer message containing the OC-OLR AVP).
The reacting node learns the Diameter application to which the
Korhonen, et al. Expires March 9, 2015 [Page 20]
Internet-Draft DOIC September 2014
overload report applies from the Application-ID of the answer message
containing the OC-OLR AVP. The reacting node MUST use this
information as an input for its traffic abatement algorithm. The
idea is that the reacting node applies different handling of the
traffic abatement, whether sent request messages are targeted to a
specific host (identified by the Diameter-Host AVP in the request) or
to any host in a realm (when only the Destination-Realm AVP is
present in the request). Note that future specifications MAY define
new OC-Report-Type AVP values that imply different handling of the
OC-OLR AVP. For example, in a form of new additional AVPs inside the
Grouped OC-OLR AVP that would define report target in a finer
granularity than just a host.
Editor's note: The above behavior for Realm reports is
inconsistent with the definition of realm reports in section
Section 6.6.
If the OC-OLR AVP is received for the first time, the reacting node
MUST create overload control state associated with the related realm
or a specific host in the realm identified in the message carrying
the OC-OLR AVP, as described in Section 4.2.1.
If the value of the OC-Sequence-Number AVP contained in the received
OC-OLR AVP is equal to or less than the value stored in an existing
overload control state, the received OC-OLR AVP SHOULD be silently
discarded. If the value of the OC-Sequence-Number AVP contained in
the received OC-OLR AVP is greater than the value stored in an
existing overload control state or there is no previously recorded
sequence number, the reacting node MUST update the overload control
state associated with the realm or the specific node in the realm.
When an overload control state is created or updated, the reacting
node MUST apply the traffic abatement requested in the OC-OLR AVP
using the algorithm announced in the OC-Supported-Features AVP
contained in the received answer message along with the OC-OLR AVP.
The validity duration of the overload information contained in the
OC-OLR AVP is either explicitly indicated in the OC-Validity-Duration
AVP or is implicitly equals to the default value (5 seconds) if the
OC-Validity-Duration AVP is absent. The reacting node MUST maintain
the validity duration in the overload control state. Once the
validity duration times out, the reacting node MUST assume the
overload condition reported in a previous OC-OLR AVP has ended.
A value of zero ("0") received in the OC-Validity-Duration in an
updated overload report indicates that the overload condition has
ended and that the overload state is no longer valid.
Korhonen, et al. Expires March 9, 2015 [Page 21]
Internet-Draft DOIC September 2014
In the case that the validity duration expires or is explicitly
signaled as being no longer valid the state associated with the
overload report MUST be removed and any abatement associated with the
overload report MUST be ended in a controlled fashion. After
removing the overload state the sequence number MUST NOT be used for
future comparisons of sequence numbers.
4.2.3. Reporting Node Behavior (Normative)
A reporting node is a Diameter node inserting an OC-OLR AVP in a
Diameter message in order to inform a reacting node about an overload
condition and request Diameter traffic abatement.
The operation on the reporting node is straight forward. The
reporting node learns the capabilities of the reacting node when it
receives the OC-Supported-Features AVP as part of any Diameter
request message. If the reporting node shares at least one common
feature with the reacting node, then the DOIC can be enabled between
these DOIC nodes See Section 4.1 for further discussion on the
capability and feature announcement.
When a traffic reduction is required due to an overload condition and
the overload control solution is supported by the sender of the
Diameter request, the reporting node MUST include an OC-Supported-
Features AVP and an OC-OLR AVP in the corresponding Diameter answer.
The OC-OLR AVP contains the required traffic reduction and the OC-
Supported-Features AVP indicates the traffic abatement algorithm to
apply. This algorithm MUST be one of the algorithms advertised by
the request sender.
A reporting node MAY rely on the OC-Validity-Duration AVP values for
the implicit overload control state cleanup on the reacting node.
However, it is RECOMMENDED that the reporting node always explicitly
indicates the end of a overload condition.
The reporting node SHOULD indicate the end of an overload occurrence
by sending a new OLR with OC-Validity-Duration set to a value of zero
("0"). The reporting node SHOULD insure that all reacting nodes
receive the updated overload report.
4.2.4. Agent Behavior (Normative)
Editor's note -- Need to add this section.
Korhonen, et al. Expires March 9, 2015 [Page 22]
Internet-Draft DOIC September 2014
4.3. Protocol Extensibility (Normative)
The overload control solution can be extended, e.g. with new traffic
abatement algorithms, new report types or other new functionality.
When defining a new extension a new feature bit MUST be defined for
the OC-Feature-Vector. This feature bit is used to communicate
support for the new feature.
The extention may also define new AVPs for use in DOIC Capability
Anouncement and for use in DOIC Overload reporting. These new AVP
should be defined to be extensions to the OC-Supported-Features and
OC-OLR AVPs defined in this document.
It should be noted that [RFC6733] defined Grouped AVP extension
mechanisms apply. This allows, for example, defining a new feature
that is mandatory to be understood even when piggybacked on an
existing applications. More specifically, the sub-AVPs inside the
OC-Supported-Features and OC-OLR AVP MAY have the M-bit set.
However, when overload control AVPs are piggybacked on top of an
existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED.
The handling of feature bits in the OC-Feature-Vector AVP that are
not associated with overload abatement algorithms MUST be specified
by the extensions that define the features.
When defining new report type values, the corresponding specification
MUST define the semantics of the new report types and how they affect
the OC-OLR AVP handling. The specification MUST also reserve a
corresponding new feature, see the OC-Supported-Features and OC-
Feature-Vector AVPs.
The OC-OLR AVP can be expanded with optional sub-AVPs only if a
legacy implementation can safely ignore them without breaking
backward compatibility for the given OC-Report-Type AVP value implied
report handling semantics. If the new sub-AVPs imply new semantics
for handling the indicated report type, then a new OC-Report-Type AVP
value MUST be defined.
New features (feature bits in the OC-Feature-Vector AVP) and report
types (in the OC-Report-Type AVP) MUST be registered with IANA. As
with any Diameter specification, new AVPs MUST also be registered
with IANA. See Section 8 for the required procedures.
Korhonen, et al. Expires March 9, 2015 [Page 23]
Internet-Draft DOIC September 2014
5. Loss Algorithm (Normative)
This section documents the Diameter overload loss abatement
algorithm.
5.1. Overview (Non normative)
The DOIC specification supports the ability for multiple overload
abatement algorithms to be specified. The abatement algorithm used
for any instance of overload is determined by the Diameter Overload
Capability Announcement process documented in Section 4.1.
The loss algorithm described in this section is the default algorithm
that must be supported by all Diameter nodes that support DOIC.
The loss algorithm is designed to be a straightforward and stateless
overload abatement algorithm. It is used by reporting nodes to
request a percentage reduction in the amount of traffic sent. The
traffic impacted by the requested reduction depends on the type of
overload report.
Reporting nodes use a strategy of applying abatement logic to the
requested percentage of request messages sent (or handled in the case
of agents) by the reacting node that are impacted by the overload
report.
From a conceptual level, the logic at the reacting node could be
outlined as follows. In this discussion assume that the reacting
node is also the sending node.
1. An overload report is received and the associated overload state
is saved by the reacting node.
2. A new Diameter request is generated by the application running on
the reacting node.
3. The reacting node determines that an active overload report
applies to the request.
4. The reacting node determines if abatement should be applied to
the request. One approach that could be taken would be to select
a random number between 1 and 100. If the random number is less
than the indicated reduction percentage then the request is given
abatement treatment, otherwise the request is given normal
routing treatment.
Korhonen, et al. Expires March 9, 2015 [Page 24]
Internet-Draft DOIC September 2014
5.2. Use of OC-Reduction-Percentage AVP
A reporting node using the loss algorithm must use the OC-Reduction-
Percentage AVP (Section 6.7 to indicated the desired percentage of
traffic reduction.)
Editor's note: The above duplicates what is in the OC-Reduction-
Percentage AVP section can probably be removed.
5.3. Reporting Node Behavior (Normative)
The method a reporting nodes uses to determine the amount of traffic
reduction required to address an overload condition is an
implementation decision.
When a reporting node that has selected the loss abatement algorithm
determines the need to request a traffic reduction it must include an
OC-OLR AVP in all response messages.
The reporting node must indicate a percentage reduction in the OC-
Reduction-Percentage AVP.
The reporting node may change the reduction percentage in subsequent
overload reports. When doing so the reporting node must conform to
overload report handing specified in Section 4.2.3.
When the reporting node determines it no longer needs a reduction in
traffic the reporting node should send an overload report indicating
the overload report is no longer valid, as specified in
Section 4.2.3.
5.4. Reacting Node Behavior (Normative)
The method a reacting node uses to determine which request messages
are given abatement treatment is an implementation decision.
When receiving an OC-OLR in an answer message where the algorithm
indicated in the OC-Supported-Features AVP is the loss algorithm, the
reacting node must attempt to apply abatement treatment to the
requested percentage of request messages sent.
Note: the loss algorithm is a stateless algorithm. As a result,
the reacting node does not guarantee that there will be an
absolute reduction in traffic sent. Rather, it guarantees that
the requested percentage of new requests will be given abatement
treatment.
Korhonen, et al. Expires March 9, 2015 [Page 25]
Internet-Draft DOIC September 2014
If reacting node comes out of the 100 percent traffic reduction as a
result of the overload report timing out, the following concerns are
RECOMMENDED to be applied. The reacting node sending the traffic
should be conservative and, for example, first send "probe" messages
to learn the overload condition of the overloaded node before
converging to any traffic amount/rate decided by the sender. Similar
concerns apply in all cases when the overload report times out unless
the previous overload report stated 0 percent reduction.
Editor's note: Need to add additional guidance to slowly increase
the rate of traffic sent to avoid a sudden spike in traffic, as
the spike in traffic could result in oscillation of the need for
overload control.
If the reacting node does not receive a an OLR in messages sent to
the formally overloaded node then the reacting node should slowly
increase the rate of traffic sent to the overloaded node.
It is suggested that the reacting node decrease the amount of traffic
given abatement treatment by 20% each second until the reduction is
completely removed and no traffic is given abatement treatment.
The goal of this behavior is to reduce the probability of overload
condition thrashing where an immediate transition from 100%
reduction to 0% reduction results in the reporting node moving
quickly back into an overload condition.
6. Attribute Value Pairs (Normative)
This section describes the encoding and semantics of the Diameter
Overload Indication Attribute Value Pairs (AVPs) defined in this
document.
When added to existing commands, both OC-Feature-Vector and OC-OLR
AVPs SHOULD have the M-bit flag cleared to avoid backward
compatibility issues.
A new application specification can incorporate the overload control
mechanism specified in this document by making it mandatory to
implement for the application and referencing this specification
normatively. In such a case, the OC-Feature-Vector and OC-OLR AVPs
reused in newly defined Diameter applications SHOULD have the M-bit
flag set. However, it is the responsibility of the Diameter
application designers to define how overload control mechanisms works
on that application.
Korhonen, et al. Expires March 9, 2015 [Page 26]
Internet-Draft DOIC September 2014
6.1. OC-Supported-Features AVP
The OC-Supported-Features AVP (AVP code TBD1) is type of Grouped and
serves for two purposes. First, it announces a node's support for
the DOIC in general. Second, it contains the description of the
supported DOIC features of the sending node. The OC-Supported-
Features AVP MUST be included in every Diameter message a DOIC
supporting node sends.
OC-Supported-Features ::= < AVP Header: TBD1 >
[ OC-Feature-Vector ]
* [ AVP ]
The OC-Feature-Vector sub-AVP is used to announce the DOIC features
supported by the DOIC node, in the form of a flag bits field in which
each bit announces one feature or capability supported by the node
(see Section 6.2). The absence of the OC-Feature-Vector AVP
indicates that only the default traffic abatement algorithm described
in this specification is supported.
A reacting node includes this AVP to indicate its capabilities to a
reporting node. For example, the reacting node may indicate which
(future defined) traffic abatement algorithms it supports in addition
to the default.
During the message exchange the DOIC nodes express their common set
of supported capabilities. The reacting node includes the OC-
Supported-Features AVP that announces what it supports. The
reporting node that sends the answer also includes the OC-Supported-
Features AVP that describes the capabilities it supports. The set of
capabilities advertised by the reporting node depends on local
policies. At least one of the announced capabilities MUST match. If
there is no single matching capability the reacting node MUST act as
if it does not implement DOIC and cease inserting any DOIC related
AVPs into any Diameter messages with this specific reacting node.
Editor's note: The last sentence conflicts with the last sentence
two paragraphs up. In reality, there will always be at least one
matching capability as all nodes supporting DOIC must support the
loss algorithm. Suggest removing the last sentence.
6.2. OC-Feature-Vector AVP
The OC-Feature-Vector AVP (AVP code TBD6) is type of Unsigned64 and
contains a 64 bit flags field of announced capabilities of a DOIC
node. The value of zero (0) is reserved.
Korhonen, et al. Expires March 9, 2015 [Page 27]
Internet-Draft DOIC September 2014
The following capabilities are defined in this document:
OLR_DEFAULT_ALGO (0x0000000000000001)
When this flag is set by the DOIC node it means that the default
traffic abatement (loss) algorithm is supported.
6.3. OC-OLR AVP
The OC-OLR AVP (AVP code TBD2) is type of Grouped and contains the
necessary information to convey an overload report. The OC-OLR AVP
does not explicitly contain all information needed by the reacting
node to decide whether a subsequent request must undergo a throttling
process with the received reduction percentage. The value of the OC-
Report-Type AVP within the OC-OLR AVP indicates which implicit
information is relevant for this decision (see Section 6.6). The
application the OC-OLR AVP applies to is the same as the Application-
Id found in the Diameter message header. The identity the OC-OLR AVP
concerns is determined from the Origin-Host AVP (and Origin-Realm AVP
as well) found from the encapsulating Diameter command. The OC-OLR
AVP is intended to be sent only by a reporting node.
OC-OLR ::= < AVP Header: TBD2 >
< OC-Sequence-Number >
< OC-Report-Type >
[ OC-Reduction-Percentage ]
[ OC-Validity-Duration ]
* [ AVP ]
The OC-Validity-Duration AVP indicates the validity time of the
overload report associated with a specific sequence number, measured
after reception of the OC-OLR AVP. The validity time MUST NOT be
updated after reception of subsequent OC-OLR AVPs with the same
sequence number. The default value for the OC-Validity-Duration AVP
value is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is
not present in the OC-OLR AVP, the default value applies.
Note that if a Diameter command were to contain multiple OC-OLR AVPs
they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs
with unknown values SHOULD be silently discarded and the event SHOULD
be logged.
Editor's note: Need to specify what happens when two reports of
the same type are received.
Korhonen, et al. Expires March 9, 2015 [Page 28]
Internet-Draft DOIC September 2014
6.4. OC-Sequence-Number AVP
The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
Its usage in the context of overload control is described in
Section 4.2.
From the functionality point of view, the OC-Sequence-Number AVP MUST
be used as a non-volatile increasing counter between two DOIC nodes.
The sequence number is only required to be unique between two DOIC
nodes. Sequence numbers are treated in a uni-directional manner,
i.e. two sequence numbers on each direction between two DOIC nodes
are not related or correlated.
When generating sequence numbers, the new sequence number MUST be
greater than any sequence number in an active overload report
previously sent by the reporting node. This property MUST hold over
a reboot of the reporting node.
6.5. OC-Validity-Duration AVP
The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
and indicates in seconds the validity time of the overload report.
The number of seconds is measured after reception of the first OC-OLR
AVP with a given value of OC-Sequence-Number AVP. The default value
for the OC-Validity-Duration AVP is 5 (i.e., 5 seconds). When the
OC-Validity-Duration AVP is not present in the OC-OLR AVP, the
default value applies. Validity duration with values above 86400
(i.e.; 24 hours) MUST NOT be used. Invalid duration values are
treated as if the OC-Validity-Duration AVP were not present and
result in the default value being used.
A timeout of the overload report has specific concerns that need to
be taken into account by the DOIC node acting on the earlier received
overload report(s). Section 6.7 discusses the impacts of timeout in
the scope of the traffic abatement algorithms.
When a reporting node has recovered from overload, it SHOULD
invalidate any existing overload reports in a timely matter. This
can be achieved by sending an updated overload report (meaning the
OLR contains a new sequence number) with the OC-Validity-Duration AVP
value set to zero ("0"). If the overload report is about to expire
naturally, the reporting node MAY choose to simply let it do so.
A reacting node MUST invalidate and remove an overload report that
expires without an explicit overload report containing an OC-
Validity-Duration value set to zero ("0").
Korhonen, et al. Expires March 9, 2015 [Page 29]
Internet-Draft DOIC September 2014
6.6. OC-Report-Type AVP
The OC-Report-Type AVP (AVP code TBD5) is type of Enumerated. The
value of the AVP describes what the overload report concerns. The
following values are initially defined:
0 A host report. The overload treatment should apply to requests
for which all of the following conditions are true:
Either the Destination-Host AVP is present in the request and its
value matches the value of the Origin-Host AVP of the received
message that contained the OC-OLR AVP; or the Destination-Host is
not present in the request but the value of peer identity
associated with the connection used to send the request matches
the value of the Origin-Host AVP of the received message that
contained the OC-OLR AVP.
The value of the Destination-Realm AVP in the request matches the
value of the Origin-Realm AVP of the received message that
contained the OC-OLR AVP.
The value of the Application-ID in the Diameter Header of the
request matches the value of the Application-ID of the Diameter
Header of the received message that contained the OC-OLR AVP.
1 A realm report. The overload treatment should apply to requests
for which all of the following conditions are true:
The Destination-Host AVP is absent in the request.
The value of the Destination-Realm AVP in the request matches the
value of the Origin-Realm AVP of the received message that
contained the OC-OLR AVP.
The value of the Application-ID in the Diameter Header of the
request matches the value of the Application-ID of the Diameter
Header of the received message that contained the OC-OLR AVP.
Editor's note: There is still an open issue on the definition of
Realm reports and whether what report types should be supported.
There is consensus that host reports should be supported. There
is discussion on Realm reports and Realm-Routed-Request reports.
The above definition applies to Realm-Routed-Request reports where
Realm reports are defined to apply to all requests that match the
realm, independent of the presence, absence or value of the
Destination-Host AVP.
Korhonen, et al. Expires March 9, 2015 [Page 30]
Internet-Draft DOIC September 2014
The default value of the OC-Report-Type AVP is 0 (i.e. the host
report).
The OC-Report-Type AVP is envisioned to be useful for situations
where a reacting node needs to apply different overload treatments
for different "types" of overload. For example, the reacting node(s)
might need to throttle differently requests sent to a specific server
(identified by the Destination-Host AVP in the request) and requests
that can be handled by any server in a realm. The example in
Appendix B.1 illustrates this usage.
6.7. OC-Reduction-Percentage AVP
The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
and describes the percentage of the traffic that the sender is
requested to reduce, compared to what it otherwise would send. The
OC-Reduction-Percentage AVP applies to the default (loss) algorithm
specified in this specification. However, the AVP can be reused for
future abatement algorithms, if its semantics fit into the new
algorithm.
The value of the Reduction-Percentage AVP is between zero (0) and one
hundred (100). Values greater than 100 are ignored. The value of
100 means that all traffic is to be throttled, i.e. the reporting
node is under a severe load and ceases to process any new messages.
The value of 0 means that the reporting node is in a stable state and
has no need for the reacting node to apply any traffic abatement.
The default value of the OC-Reduction-Percentage AVP is 0. When the
OC-Reduction-Percentage AVP is not present in the overload report,
the default value applies.
6.8. Attribute Value Pair flag rules
Korhonen, et al. Expires March 9, 2015 [Page 31]
Internet-Draft DOIC September 2014
+---------+
|AVP flag |
|rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------+----+----+
|OC-Supported-Features TBD1 x.x Grouped | | V |
+--------------------------------------------------+----+----+
|OC-OLR TBD2 x.x Grouped | | V |
+--------------------------------------------------+----+----+
|OC-Sequence-Number TBD3 x.x Unsigned64 | | V |
+--------------------------------------------------+----+----+
|OC-Validity-Duration TBD4 x.x Unsigned32 | | V |
+--------------------------------------------------+----+----+
|OC-Report-Type TBD5 x.x Enumerated | | V |
+--------------------------------------------------+----+----+
|OC-Reduction | | |
| -Percentage TBD8 x.x Unsigned32 | | V |
+--------------------------------------------------+----+----+
|OC-Feature-Vector TBD6 x.x Unsigned64 | | V |
+--------------------------------------------------+----+----+
As described in the Diameter base protocol [RFC6733], the M-bit
setting for a given AVP is relevant to an application and each
command within that application that includes the AVP.
The Diameter overload control AVPs SHOULD always be sent with the
M-bit cleared when used within existing Diameter applications to
avoid backward compatibility issues. Otherwise, when reused in newly
defined Diameter applications, the DOC related AVPs SHOULD have the
M-bit set.
7. Error Response Codes
Editor's note: This section depends on resolution of issue #27.
8. IANA Considerations
8.1. AVP codes
New AVPs defined by this specification are listed in Section 6. All
AVP codes allocated from the 'Authentication, Authorization, and
Accounting (AAA) Parameters' AVP Codes registry.
Korhonen, et al. Expires March 9, 2015 [Page 32]
Internet-Draft DOIC September 2014
8.2. New registries
Three new registries are needed under the 'Authentication,
Authorization, and Accounting (AAA) Parameters' registry.
Section 6.2 defines a new "Overload Control Feature Vector" registry
including the initial assignments. New values can be added into the
registry using the Specification Required policy [RFC5226]. See
Section 6.2 for the initial assignment in the registry.
Section 6.6 defines a new "Overload Report Type" registry with its
initial assignments. New types can be added using the Specification
Required policy [RFC5226].
9. Security Considerations
This mechanism gives Diameter nodes the ability to request that
downstream nodes send fewer Diameter requests. Nodes do this by
exchanging overload reports that directly affect this reduction.
This exchange is potentially subject to multiple methods of attack,
and has the potential to be used as a Denial-of-Service (DoS) attack
vector.
Overload reports may contain information about the topology and
current status of a Diameter network. This information is
potentially sensitive. Network operators may wish to control
disclosure of overload reports to unauthorized parties to avoid its
use for competitive intelligence or to target attacks.
Diameter does not include features to provide end-to-end
authentication, integrity protection, or confidentiality. This may
cause complications when sending overload reports between non-
adjacent nodes.
9.1. Potential Threat Modes
The Diameter protocol involves transactions in the form of requests
and answers exchanged between clients and servers. These clients and
servers may be peers, that is,they may share a direct transport (e.g.
TCP or SCTP) connection, or the messages may traverse one or more
intermediaries, known as Diameter Agents. Diameter nodes use TLS,
DTLS, or IPSec to authenticate peers, and to provide confidentiality
and integrity protection of traffic between peers. Nodes can make
authorization decisions based on the peer identities authenticated at
the transport layer.
When agents are involved, this presents an effectively hop-by-hop
trust model. That is, a Diameter client or server can authorize an
Korhonen, et al. Expires March 9, 2015 [Page 33]
Internet-Draft DOIC September 2014
agent for certain actions, but it must trust that agent to make
appropriate authorization decisions about its peers, and so on.
Since confidentiality and integrity protection occurs at the
transport layer. Agents can read, and perhaps modify, any part of a
Diameter message, including an overload report.
There are several ways an attacker might attempt to exploit the
overload control mechanism. An unauthorized third party might inject
an overload report into the network. If this third party is upstream
of an agent, and that agent fails to apply proper authorization
policies, downstream nodes may mistakenly trust the report. This
attack is at least partially mitigated by the assumption that nodes
include overload reports in Diameter answers but not in requests.
This requires an attacker to have knowledge of the original request
in order to construct a response. Therefore, implementations SHOULD
validate that an answer containing an overload report is a properly
constructed response to a pending request prior to acting on the
overload report.
A similar attack involves an otherwise authorized Diameter node that
sends an inappropriate overload report. For example, a server for
the realm "example.com" might send an overload report indicating that
a competitor's realm "example.net" is overloaded. If other nodes act
on the report, they may falsely believe that "example.net" is
overloaded, effectively reducing that realm's capacity. Therefore,
it's critical that nodes validate that an overload report received
from a peer actually falls within that peer's responsibility before
acting on the report or forwarding the report to other peers. For
example, an overload report from an peer that applies to a realm not
handled by that peer is suspect.
An attacker might use the information in an overload report to assist
in certain attacks. For example, an attacker could use information
about current overload conditions to time a DoS attack for maximum
effect, or use subsequent overload reports as a feedback mechanism to
learn the results of a previous or ongoing attack.
9.2. Denial of Service Attacks
Diameter overload reports can cause a node to cease sending some or
all Diameter requests for an extended period. This makes them a
tempting vector for DoS tacks. Furthermore, since Diameter is almost
always used in support of other protocols, a DoS attack on Diameter
is likely to impact those protocols as well. Therefore, Diameter
nodes MUST NOT honor or forward overload reports from unauthorized or
otherwise untrusted sources.
Korhonen, et al. Expires March 9, 2015 [Page 34]
Internet-Draft DOIC September 2014
9.3. Non-Compliant Nodes
When a Diameter node sends an overload report, it cannot assume that
all nodes will comply. A non-compliant node might continue to send
requests with no reduction in load. Requirement 28 [RFC7068]
indicates that the overload control solution cannot assume that all
Diameter nodes in a network are necessarily trusted, and that
malicious nodes not be allowed to take advantage of the overload
control mechanism to get more than their fair share of service.
In the absence of an overload control mechanism, Diameter nodes need
to implement strategies to protect themselves from floods of
requests, and to make sure that a disproportionate load from one
source does not prevent other sources from receiving service. For
example, a Diameter server might reject a certain percentage of
requests from sources that exceed certain limits. Overload control
can be thought of as an optimization for such strategies, where
downstream nodes never send the excess requests in the first place.
However, the presence of an overload control mechanism does not
remove the need for these other protection strategies.
9.4. End-to End-Security Issues
The lack of end-to-end security features makes it far more difficult
to establish trust in overload reports that originate from non-
adjacent nodes. Any agents in the message path may insert or modify
overload reports. Nodes must trust that their adjacent peers perform
proper checks on overload reports from their peers, and so on,
creating a transitive-trust requirement extending for potentially
long chains of nodes. Network operators must determine if this
transitive trust requirement is acceptable for their deployments.
Nodes supporting Diameter overload control MUST give operators the
ability to select which peers are trusted to deliver overload
reports, and whether they are trusted to forward overload reports
from non-adjacent nodes.
The lack of end-to-end confidentiality protection means that any
Diameter agent in the path of an overload report can view the
contents of that report. In addition to the requirement to select
which peers are trusted to send overload reports, operators MUST be
able to select which peers are authorized to receive reports. A node
MUST not send an overload report to a peer not authorized to receive
it. Furthermore, an agent MUST remove any overload reports that
might have been inserted by other nodes before forwarding a Diameter
message to a peer that is not authorized to receive overload reports.
At the time of this writing, the DIME working group is studying
requirements for adding end-to-end security
Korhonen, et al. Expires March 9, 2015 [Page 35]
Internet-Draft DOIC September 2014
[I-D.ietf-dime-e2e-sec-req] features to Diameter. These features,
when they become available, might make it easier to establish trust
in non-adjacent nodes for overload control purposes. Readers should
be reminded, however, that the overload control mechanism encourages
Diameter agents to modify AVPs in, or insert additional AVPs into,
existing messages that are originated by other nodes. If end-to-end
security is enabled, there is a risk that such modification could
violate integrity protection. The details of using any future
Diameter end-to-end security mechanism with overload control will
require careful consideration, and are beyond the scope of this
document.
10. Contributors
The following people contributed substantial ideas, feedback, and
discussion to this document:
o Eric McMurry
o Hannes Tschofenig
o Ulrich Wiehe
o Jean-Jacques Trottin
o Maria Cruz Bartolome
o Martin Dolly
o Nirav Salot
o Susan Shishufeng
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
Korhonen, et al. Expires March 9, 2015 [Page 36]
Internet-Draft DOIC September 2014
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
11.2. Informative References
[Cx] 3GPP, , "ETSI TS 129 229 V11.4.0", August 2013.
[I-D.ietf-dime-e2e-sec-req]
Tschofenig, H., Korhonen, J., Zorn, G., and K. Pillay,
"Diameter AVP Level Security: Scenarios and Requirements",
draft-ietf-dime-e2e-sec-req-00 (work in progress),
September 2013.
[PCC] 3GPP, , "ETSI TS 123 203 V11.12.0", December 2013.
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
Loughney, "Diameter Credit-Control Application", RFC 4006,
August 2005.
[RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou,
"Clarifications on the Routing of Diameter Requests Based
on the Username and the Realm", RFC 5729, December 2009.
[RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control
Requirements", RFC 7068, November 2013.
[S13] 3GPP, , "ETSI TS 129 272 V11.9.0", December 2012.
Appendix A. Issues left for future specifications
The base solution for the overload control does not cover all
possible use cases. A number of solution aspects were intentionally
left for future specification and protocol work.
A.1. Additional traffic abatement algorithms
This specification describes only means for a simple loss based
algorithm. Future algorithms can be added using the designed
solution extension mechanism. The new algorithms need to be
registered with IANA. See Sections 6.1 and 8 for the required IANA
steps.
A.2. Agent Overload
This specification focuses on Diameter endpoint (server or client)
overload. A separate extension will be required to outline the
handling the case of agent overload.
Korhonen, et al. Expires March 9, 2015 [Page 37]
Internet-Draft DOIC September 2014
A.3. DIAMETER_TOO_BUSY clarifications
The current [RFC6733] behavior in a case of DIAMETER_TOO_BUSY is
somewhat under specified. For example, there is no information how
long the specific Diameter node is willing to be unavailable. A
specification updating [RFC6733] should clarify the handling of
DIAMETER_TOO_BUSY from the error answer initiating Diameter node
point of view and from the original request initiating Diameter node
point of view. Further, the inclusion of possible additional
information providing AVPs should be discussed and possible be
recommended to be used.
Appendix B. Examples
B.1. Mix of Destination-Realm routed requests and Destination-Host
routed requests
Diameter allows a client to optionally select the destination server
of a request, even if there are agents between the client and the
server. The client does this using the Destination-Host AVP. In
cases where the client does not care if a specific server receives
the request, it can omit Destination-Host and route the request using
the Destination-Realm and Application Id, effectively letting an
agent select the server.
Clients commonly send mixtures of Destination-Host and Destination-
Realm routed requests. For example, in an application that uses user
sessions, a client typically won't care which server handles a
session-initiating requests. But once the session is initiated, the
client will send all subsequent requests in that session to the same
server. Therefore it would send the initial request with no
Destination-Host AVP. If it receives a successful answer, the client
would copy the Origin-Host value from the answer message into a
Destination-Host AVP in each subsequent request in the session.
An agent has very limited options in applying overload abatement to
requests that contain Destination-Host AVPs. It typically cannot
route the request to a different server than the one identified in
Destination-Host. It's only remaining options are to throttle such
requests locally, or to send an overload report back towards the
client so the client can throttle the requests. The second choice is
usually more efficient, since it prevents any throttled requests from
being sent in the first place, and removes the agent's need to send
errors back to the client for each dropped request.
On the other hand, an agent has much more leeway to apply overload
abatement for requests that do not contain Destination-Host AVPs. If
the agent has multiple servers in its peer table for the given realm
Korhonen, et al. Expires March 9, 2015 [Page 38]
Internet-Draft DOIC September 2014
and application, it can route such requests to other, less overloaded
servers.
If the overload severity increases, the agent may reach a point where
there is not sufficient capacity across all servers to handle even
realm-routed requests. In this case, the realm itself can be
considered overloaded. The agent may need the client to throttle
realm-routed requests in addition to Destination-Host routed
requests. The overload severity may be different for each server,
and the severity for the realm at is likely to be different than for
any specific server. Therefore, an agent may need to forward, or
originate, multiple overload reports with differing ReportType and
Reduction-Percentage values.
Figure 2 illustrates such a mixed-routing scenario. In this example,
the servers S1, S2, and S3 handle requests for the realm "realm".
Any of the three can handle requests that are not part of a user
session (i.e. routed by Destination-Realm). But once a session is
established, all requests in that session must go to the same server.
Client Agent S1 S2 S3
| | | | |
|(1) Request (DR:realm) | |
|-------->| | | |
| | | | |
| | | | |
| |Agent selects S1 | |
| | | | |
| | | | |
| | | | |
| |(2) Request (DR:realm) |
| |-------->| | |
| | | | |
| | | | |
| | |S1 overloaded, returns OLR
| | | | |
| | | | |
| | | | |
| |(3) Answer (OR:realm,OH:S1,OLR:RT=DH)
| |<--------| | |
| | | | |
| | | | |
| |sees OLR,routes DR traffic to S2&S3
| | | | |
| | | | |
| | | | |
|(4) Answer (OR:realm,OH:S1, OLR:RT=DH) |
|<--------| | | |
Korhonen, et al. Expires March 9, 2015 [Page 39]
Internet-Draft DOIC September 2014
| | | | |
| | | | |
|Client throttles requests with DH:S1 |
| | | | |
| | | | |
| | | | |
|(5) Request (DR:realm) | |
|-------->| | | |
| | | | |
| | | | |
| |Agent selects S2 | |
| | | | |
| | | | |
| | | | |
| |(6) Request (DR:realm) |
| |------------------>| |
| | | | |
| | | | |
| | | |S2 is overloaded...
| | | | |
| | | | |
| | | | |
| |(7) Answer (OH:S2, OLR:RT=DH)|
| |<------------------| |
| | | | |
| | | | |
| |Agent sees OLR, realm now overloaded
| | | | |
| | | | |
| | | | |
|(8) Answer (OR:realm,OH:S2, OLR:RT=DH, OLR: RT=R)
|<--------| | | |
| | | | |
| | | | |
|Client throttles DH:S1, DH:S2, and DR:realm
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
Figure 2: Mix of Destination-Host and Destination-Realm Routed
Requests
1. The client sends a request with no Destination-Host AVP (that is,
a Destination-Realm routed request.)
Korhonen, et al. Expires March 9, 2015 [Page 40]
Internet-Draft DOIC September 2014
2. The agent follows local policy to select a server from its peer
table. In this case, the agent selects S2 and forwards the
request.
3. S1 is overloaded. It sends a answer indicating success, but also
includes an overload report. Since the overload report only
applies to S1, the ReportType is "Destination-Host".
4. The agent sees the overload report, and records that S1 is
overloaded by the value in the Reduction-Percentage AVP. It
begins diverting the indicated percentage of realm-routed traffic
from S1 to S2 and S3. Since it can't divert Destination-Host
routed traffic, it forwards the overload report to the client.
This effectively delegates the throttling of traffic with
Destination-Host:S1 to the client.
5. The client sends another Destination-Realm routed request.
6. The agent selects S2, and forwards the request.
7. It turns out that S2 is also overloaded, perhaps due to all that
traffic it took over for S1. S2 returns an successful answer
containing an overload report. Since this report only applies to
S2, the ReportType is "Destination-Host".
8. The agent sees that S2 is also overloaded by the value in
Reduction-Percentage. This value is probably different than the
value from S1's report. The agent diverts the remaining traffic
to S3 as best as it can, but it calculates that the remaining
capacity across all three servers is no longer sufficient to
handle all of the realm-routed traffic. This means the realm
itself is overloaded. The realm's overload percentage is most
likely different than that for either S1 or S2. The agent
forward's S2's report back to the client in the Diameter answer.
Additionally, the agent generates a new report for the realm of
"realm", and inserts that report into the answer. The client
throttles requests with Destination-Host:S1 at one rate, requests
with Destination-Host:S2 at another rate, and requests with no
Destination-Host AVP at yet a third rate. (Since S3 has not
indicated overload, the client does not throttle requests with
Destination-Host:S3.)
Appendix C. Restructuring of -02 version of the draft
This section captures the initial plan for restructuring the DOIC
specification from the -02 version to the new -03 version.
1. Introduction (non normative)
Korhonen, et al. Expires March 9, 2015 [Page 41]
Internet-Draft DOIC September 2014
-- Existing Text from section 1. --
2. Terminology and Abbreviations (non normative)
-- Existing Text from section 2. --
3. Solution Overview (Non normative)
-- Existing text from section 3. --
3.1 Overload Control Endpoints (Non normative)
-- New text leveraging text from existing section 5.1 --
3.2 Piggybacking Principle (Non normative)
-- Existing text from existing section 5.2, with enhancements --
3.3 DOIC Capability Discovery (Non normative)
-- New text leveraging text from existing section 5.3 --
3.4 DOIC Overload Condition Reporting (Non normative)
-- New text --
3.5 DOIC Extensibility (Non normative)
-- New text leveraging text from existing Section 5.4 --
3.5 Simplified Example Architecture (Non normative)
-- Existing text from section 3.1.6, with enhancements --
3.6 Considerations for Applications Integrating the DOIC Solution (Non normative)
-- New text --
3.6.1. Application Classification (Non normative)
-- Existing text from section 3.1.1 --
3.6.2. Application Type Overload Implications (Non normative)
-- Existing text from section 3.1.2 --
3.6.3. Request Transaction Classification (Non normative)
-- Existing text from section 3.1.3 --
3.6.4. Request Type Overload Implications (Non normative)
-- Existing text from section 3.1.4 --
4. Solution Procedures (Normative)
4.1 Capability Announcement (Normative)
-- Existing text from section 5.3 --
4.1.1. Reacting Node Behavior (Normative)
-- Existing text from section 5.3.1 --
4.1.2. Reporting Node Behavior (Normative)
-- Existing text from section 5.3.2 --
4.1.3. Agent Behavior (Normative)
-- Existing text from section 5.3.3 --
4.2. Overload Report Processing (Normative)
4.2.1. Overload Control State (Normative)
-- Existing text from section 5.5.1 --
4.2.2. Reacting Node Behavior (Normative)
-- Existing text from section 5.5.2 --
4.2.3. Reporting Node Behavior (Normative)
-- Existing text from section 5.5.3 --
4.2.4. Agent Behavior (Normative)
-- Existing text from section 5.5.4 --
4.3. Protocol Extensibility (Normative)
-- Existing text from section 5.4 --
5. Loss Algorithm (Normative)
Korhonen, et al. Expires March 9, 2015 [Page 42]
Internet-Draft DOIC September 2014
-- New text pulling from information spread through the document --
5.1. Overview (Non normative)
-- New text pulling from information spread through the document --
5.2. Reporting Node Behavior (Normative)
-- New text pulling from information spread through the document --
5.3. Reacting Node Behavior (Normative)
-- New text pulling from information spread through the document --
6. Attribute Value Pairs (Normative)
-- Existing text from section 4. --
6.1. OC-Supported-Features AVP
-- Existing text from section 4.1 --
6.2. OC-Feature-Vector AVP
-- Existing text from section 4.2 --
6.3. OC-OLR AVP
-- Existing text from section 4.3 --
6.4. OC-Sequence-Number AVP
-- Existing text from section 4.4 --
6.5. OC-Validity-Duration AVP
-- Existing text from section 4.5 --
6.6. OC-Report-Type AVP
-- Existing text from section 4.6 --
6.7. OC-Reduction-Percentage AVP
-- Existing text from section 4.7 --
6.8. Attribute Value Pair flag rules
-- Existing text from section 4.8 --
7. Error Response Codes
-- New text based on resolution of issue --
8. IANA Considerations
-- Existing text from section 7. --
8.1. AVP codes
-- Existing text from section 7.1 --
8.2. New registries
-- Existing text from section 7.2 --
9. Security Considerations
-- Existing text from section 8. --
9.1. Potential Threat Modes
-- Existing text from section 8.1 --
9.2. Denial of Service Attacks
-- Existing text from section 8.2 --
9.3. Non-Compliant Nodes
-- Existing text from section 8.3 --
9.4. End-to End-Security Issues
-- Existing text from section 8.4 --
10. Contributors
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Issues left for future specifications
Korhonen, et al. Expires March 9, 2015 [Page 43]
Internet-Draft DOIC September 2014
A.1. Additional traffic abatement algorithms
A.2. Agent Overload
A.3. DIAMETER_TOO_BUSY clarifications
A.4. Per reacting node reports
Appendix B. Examples
B.1. Mix of Destination-Realm routed requests and Destination-
Host routed requests
Authors' Addresses
Authors' Addresses
Jouni Korhonen (editor)
Broadcom
Porkkalankatu 24
Helsinki FIN-00180
Finland
Email: jouni.nospam@gmail.com
Steve Donovan (editor)
Oracle
7460 Warren Parkway
Frisco, Texas 75034
United States
Email: srdonovan@usdonovans.com
Ben Campbell
Oracle
7460 Warren Parkway
Frisco, Texas 75034
United States
Email: ben@nostrum.com
Lionel Morand
Orange Labs
38/40 rue du General Leclerc
Issy-Les-Moulineaux Cedex 9 92794
France
Phone: +33145296257
Email: lionel.morand@orange.com
Korhonen, et al. Expires March 9, 2015 [Page 44]
Jump to Line
Something went wrong with that request. Please try again.
--------------060503040209050300020606-- From nobody Thu Oct 9 09:38:00 2014 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 3B4971AD190 for ; Thu, 9 Oct 2014 09:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.38 X-Spam-Level: *** X-Spam-Status: No, score=3.38 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=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 7g4Ym60O62pi for ; Thu, 9 Oct 2014 09:37:37 -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 D154C1AD182 for ; Thu, 9 Oct 2014 09:37:36 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62417 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XcGiU-0007a3-Dh for dime@ietf.org; Thu, 09 Oct 2014 09:37:35 -0700 Message-ID: <5436B9C5.7080007@usdonovans.com> Date: Thu, 09 Oct 2014 11:37:25 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <5436A942.1010400@usdonovans.com> In-Reply-To: <5436A942.1010400@usdonovans.com> Content-Type: multipart/mixed; boundary="------------060008090505020207050209" 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/f4j8ek5eLGyMDL9oYcUyTkStMsM Subject: Re: [Dime] Prep for next weeks DIME interim meeting 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, 09 Oct 2014 16:37:48 -0000 This is a multi-part message in MIME format. --------------060008090505020207050209 Content-Type: multipart/alternative; boundary="------------040802070501020609060109" --------------040802070501020609060109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here's a cleaner version of the .txt document. Steve On 10/9/14, 10:26 AM, Steve Donovan wrote: > All, > > As we prepare for next weeks interim meeting, please remember to use > the following as the source document: > > https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-04.txt > > > I've attached a copy for everyone's convenience. > > Regards, > > Steve > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------040802070501020609060109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here's a cleaner version of the .txt document.

Steve

On 10/9/14, 10:26 AM, Steve Donovan wrote:
All,

As we prepare for next weeks interim meeting, please remember to use the following as the source document:

https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-04.txt

I've attached a copy for everyone's convenience.

Regards,

Steve 


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

--------------040802070501020609060109-- --------------060008090505020207050209 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-dime-ovli-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-dime-ovli-04.txt" Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed. Internet-Draft Broadcom Intended status: Standards Track S. Donovan, Ed. Expires: April 12, 2015 B. Campbell Oracle L. Morand Orange Labs October 9, 2014 Diameter Overload Indication Conveyance draft-ietf-dime-ovli-04.txt Abstract This specification documents a Diameter Overload Control (DOC) base solution and the dissemination of the overload report information. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 12, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Korhonen, et al. Expires April 12, 2015 [Page 1] Internet-Draft DOIC October 2014 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Piggybacking Principle (Non normative) . . . . . . . . . 6 3.2. DOIC Capability Announcement (Non normative) . . . . . . 7 3.3. DOIC Overload Condition Reporting (Non normative) . . . . 9 3.4. DOIC Extensibility (Non normative) . . . . . . . . . . . 10 3.5. Simplified Example Architecture (Non normative) . . . . . 10 3.6. Considerations for Applications Integrating the DOIC Solution (Non normative) . . . . . . . . . . . . . . . . 11 3.6.1. Application Classification (Non normative) . . . . . 11 3.6.2. Application Type Overload Implications (Non normative) . . . . . . . . . . . . . . . . . . . . . 12 3.6.3. Request Transaction Classification (Non normative) . 14 3.6.4. Request Type Overload Implications (Non normative) . 14 4. Solution Procedures (Normative) . . . . . . . . . . . . . . . 16 4.1. Capability Announcement (Normative) . . . . . . . . . . . 16 4.1.1. Reacting Node Behavior (Normative) . . . . . . . . . 16 4.1.2. Reporting Node Behavior (Normative) . . . . . . . . 17 4.1.3. Agent Behavior (Normative) . . . . . . . . . . . . . 18 4.2. Overload Report Processing (Normative) . . . . . . . . . 18 4.2.1. Overload Control State (Normative) . . . . . . . . . 18 4.2.2. Reacting Node Behavior (Normative) . . . . . . . . . 20 4.2.3. Reporting Node Behavior (Normative) . . . . . . . . 22 4.2.4. Agent Behavior (Normative) . . . . . . . . . . . . . 22 4.3. Protocol Extensibility (Normative) . . . . . . . . . . . 23 5. Loss Algorithm (Normative) . . . . . . . . . . . . . . . . . 24 5.1. Overview (Non normative) . . . . . . . . . . . . . . . . 24 5.2. Use of OC-Reduction-Percentage AVP . . . . . . . . . . . 25 5.3. Reporting Node Behavior (Normative) . . . . . . . . . . . 25 5.4. Reacting Node Behavior (Normative) . . . . . . . . . . . 25 6. Attribute Value Pairs (Normative) . . . . . . . . . . . . . . 26 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 27 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 27 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 28 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 29 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 29 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 30 Korhonen, et al. Expires April 12, 2015 [Page 2] Internet-Draft DOIC October 2014 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 31 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 31 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 32 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 33 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 33 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 34 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 35 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 35 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 11.1. Normative References . . . . . . . . . . . . . . . . . . 36 11.2. Informative References . . . . . . . . . . . . . . . . . 37 Appendix A. Issues left for future specifications . . . . . . . 37 A.1. Additional traffic abatement algorithms . . . . . . . . . 37 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 37 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 38 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 38 B.1. Mix of Destination-Realm routed requests and Destination- Host routed requests . . . . . . . . . . . . . . . . . . 38 Appendix C. Restructuring of -02 version of the draft . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction This specification defines a base solution for Diameter Overload Control (DOC), refered to as Diameter Overload Indication Conveyance (DOIC). The requirements for the solution are described and discussed in the corresponding design requirements document [RFC7068]. Note that the overload control solution defined in this specification does not address all the requirements listed in [RFC7068]. A number of overload control related features are left for the future specifications. The solution defined in this specification addresses Diameter overload control between Diameter nodes that support the DOIC solution. Furthermore, the solution is designed to apply to existing and future Diameter applications, requires no changes to the Diameter base protocol [RFC6733] and is deployable in environments where some Diameter nodes do not implement the Diameter overload control solution defined in this specification. Korhonen, et al. Expires April 12, 2015 [Page 3] Internet-Draft DOIC October 2014 2. Terminology and Abbreviations Abatement Algorithm An algorithm requested by reporting nodes and used by reacting nodes to reduce the amount of traffic sent during an occurrence of overload control. Throttling Throttling is the reduction of the number of requests sent to an entity. Throttling can include a client dropping requests, or an agent rejecting requests with appropriate error responses. Clients and agents can also choose to redirect throttled requests to some other entity or entities capable of handling them. Editor's note: Propose to add a definition of Abatement to include both throttling and diversion (redirecting of messages) actions. Then to modify this definition to include just the rejecting of requests and adding a definition of diversion. Reporting Node A Diameter node that generates an overload report. (This may or may not be the overloaded node.) Reacting Node A Diameter node that consumes and acts upon a report. Note that "act upon" does not necessarily mean the reacting node applies an abatement algorithm; it might decide to delegate that downstream, in which case it also becomes a "reporting node". Overload Control State (OCS) State describing an occurrence of overload control maintained by reporting and reacting nodes. Overload Report (OLR) A set of AVPs sent by a reporting node indicating the start or continuation of an occurrence of overload control. 3. Solution Overview The Diameter Overload Information Conveyance (DOIC) mechanism allows Diameter nodes to request other nodes to perform overload abatement Korhonen, et al. Expires April 12, 2015 [Page 4] Internet-Draft DOIC October 2014 actions, that is, actions to reduce the load offered to the overloaded node or realm. A Diameter node that supports DOIC is known as a "DOIC node". Any Diameter node can act as a DOIC node, including clients, servers, and agents. DOIC nodes are further divided into "Reporting Nodes" and "Reacting Nodes." A reporting node requests overload abatement by sending an Overload Report (OLR) to one or more reacting nodes. A reacting node consumes OLRs, and performs whatever actions are needed to fulfill the abatement requests included in the OLRs. A Reporting node may report overload on its own behalf, or on behalf of other (typically upstream) nodes. Likewise, a reacting node may perform overload abatement on its own behalf, or on behalf of other (typically downstream) nodes. A node's role as a DOIC node is independent of its Diameter role. For example, Diameter relay and proxy agents may act as DOIC nodes, even though they are not endpoints in the Diameter sense. Since Diameter enables bi-directional applications, where Diameter servers can send requests towards Diameter clients, a given Diameter node can simultaneously act as a reporting node and a reacting node. Likewise, a relay or proxy agent may act as a reacting node from the perspective of upstream nodes, and a reporting node from the perspective of downstream nodes. DOIC nodes do not generate new messages to carry DOIC related information. Rather, they "piggyback" DOIC information over existing Diameter messages by inserting new AVPs into existing Diameter requests and responses. Nodes indicate support for DOIC, and any needed DOIC parameters by inserting an OC_Supported_Features AVP (Section 6.2) into existing requests and responses. Reporting nodes send OLRs by inserting OC-OLR AVPs (Section 6.3). A given OLR applies to the Diameter realm and application of the Diameter message that carries it. If a reporting node supports more than one realm and/or application, it reports independently for each combination of realm and application. Similarly, OC-Feature-Vector AVPs apply to the realm and application of the enclosing message. This implies that a node may support DOIC for one application and/or realm, but not another, and may indicate different DOIC parameters for each application and realm for which it supports DOIC. Reacting nodes perform overload abatement according to an agreed-upon abatement algorithm. An abatement algorithm defines the meaning of the parameters of an OLR, and the procedures required for overload abatement. This document specifies a single must-support algorithm, Korhonen, et al. Expires April 12, 2015 [Page 5] Internet-Draft DOIC October 2014 namely the "loss" algorithm Section 5). Future specifications may introduce new algorithms. Overload conditions may vary in scope. For example, a single Diameter node may be overloaded, in which case reacting nodes may reasonably attempt to send throttled requests to other destinations or via other agents. On the other hand, an entire Diameter realm may be overloaded, in which case such attempts would do harm. DOIC OLRs have a concept of "report type" (Section 6.6), where the type defines such behaviors. Report types are extensible. This document defines report types for overload of a specific server, and for overload of an entire realm. A report of type host is sent to indicate the overload of a specific server for the application-id indicated in the transaction. When receiving an OLR of type host, a reacting node applies overload abatement to what is referred to in this document as host-routed requests. This is the set of requests that the reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node. The reacting node applies overload abatement on those host-routed requests which the reacting node knows will be served by the server that matches the Origin-Host AVP of the received message that contained the received OLR of type host. A report type of realm is sent to indicate the overload of all servers in a realm for the application-id. When receiving an OLR of type realm, a reacting node applies overload abatement to what is referred to in this document as realm-routed requests. This is the set of requests that are not host-routed as defined in the previous paragraph. While a reporting node sends OLRs to "adjacent" reacting nodes, nodes that are "adjacent" for DOIC purposes may not be adjacent from a Diameter, or transport, perspective. For example, one or more Diameter agents that do not support DOIC may exist between a given pair of reporting and reacting nodes, as long as those agents pass unknown AVPs through unmolested. The report types described in this document can safely pass through non-supporting agents. This may not be true for report types defined in future specifications. Documents that introduce new report types MUST describe any limitations on their use across non-supporting agents. 3.1. Piggybacking Principle (Non normative) The overload control AVPs defined in this specification have been designed to be piggybacked on top of existing application message exchanges. This is made possible by adding overload control top Korhonen, et al. Expires April 12, 2015 [Page 6] Internet-Draft DOIC October 2014 level AVPs, the OC-OLR AVP and the OC-Supported-Features AVP as optional AVPs into existing commands when the corresponding Command Code Format (CCF) specification allows adding new optional AVPs (see Section 1.3.4 of [RFC6733]). Reacting nodes indicate support for DOIC by including the OC- Supported-Features AVP all request messages originated or relayed by the Diameter node. Reporting nodes indicate support for DOIC by including the OC- Supported-Features AVP in all answer messages originated or relayed by the Diameter node. Reporting nodes also include overload reports using the OC-OLR AVP in answer messages. Note: There is no new Diameter application defined to carry overload related AVPs. The DOIC AVPs are carried in existing Diameter application messages. Note that the overload control solution does not have fixed server and client roles. The DOIC node role is determined based on the message type: whether the message is a request (i.e. sent by a "reacting node") or an answer (i.e. send by a "reporting node"). Therefore, in a typical "client-server" deployment, the "client" MAY report its overload condition to the "server" for any server initiated message exchange. An example of such is the server requesting a re-authentication from a client. 3.2. DOIC Capability Announcement (Non normative) The DOIC solutions supports the ability for Diameter nodes to determine if other nodes in the path of a request support the solution. This capability is refered to as DOIC Capability Announcement (DCA) and is separate from Diameter Capability Exchange. The DCA mechanism is built around the piggybacking principle used for transporting Diameter overload AVPs. This includes both DCA AVPs and AVPs associated with Diameter overload reports. This allows for the DCA AVPs to be carried across Diameter nodes that do not support the DOIC solution. The DCA mechanism uses the OC-Supported-Features AVPs to indicate the Diameter overload features supported. The first node in the path of a Diameter request that supports the DOIC solution inserts the OC-Supported-Feature AVP in the request message. This includes an indication that it supports the loss overload abatement algorithm defined in this specification (see Section 5). This insures that there is at least one commonly Korhonen, et al. Expires April 12, 2015 [Page 7] Internet-Draft DOIC October 2014 supported overload abatement algorithm between the reporting node and the reacting nodes in the path of the request. DOIC must support deployments where Diameter Clients and/or Diameter servers do not support the DOIC solution. In this scenario, it is assumed that Diameter Agents that support the DOIC solution will handle overload abatement for the non supporting clients. In this case the DOIC agent will insert the OC- Supporting-Features AVP in requests that do not already contain one, telling the reporting node that there is a DOIC node that will handle overload abatement. The reporting node inserts the OC-Supported-Feature AVP in all answer messages to requests that contained the OC-Supported-Feature AVP. The contents of the reporting node's OC-Supported-Feature AVP indicate the set of Diameter overload features supported by the reporting node with one exception. The reporting node only includes an indication of support for one overload abatement algorithm. This is the algorithm that the reporting node intends to use should it enter an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports. Note that the loss algorithm defined in this document is a stateless abatement algorithm. As a result it does not require any actions by reacting nodes prior to the receipt of an overload report. Stateful abatement algorithms that base the abatement logic on a history of request messages sent might require reacting nodes to maintain state to insure that overload reports can be properly handled. The individual features supported by the DOIC nodes are indicated in the OC-Feature-Vector AVP. Any semantics associated with the features will be defined in extension specifications that introduce the features. The DCA mechanism must also support the scenario where the set of features supported by the sender of a request and by agents in the path of a request differ. In this case, the agent updates the OC- Supported-Feature AVP to reflect the mixture of the two sets of supported features. The logic to determine the content of the modified OC-Supported- Feature AVP is out-of-scope for this specification and is left to implementation decisions. Care must be taken in doing so not to introduce interoperability issues for downstream or upstream DOIC nodes. Korhonen, et al. Expires April 12, 2015 [Page 8] Internet-Draft DOIC October 2014 3.3. DOIC Overload Condition Reporting (Non normative) As with DOIC Capability Announcement, Overload Condition Reporting uses new AVPs (Section 6.3) to indicate an overload condition. The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP includes the type of report, an overload report ID, the length of time that the report is valid and abatement algorithm specific AVPs. Two types of overload reports are defined in this document, host reports and realm reports. Host reports apply to traffic that is sent to a specific Diameter host. The applies to requests that contain the Destination-Host AVP that contains a DiameterIdentity that matches that of the overload report. These requests are referred to as host-routed requests. A host report also applies to realm-routed requests, requests that do not have a Destination-Host AVP, when the selected route for the request is a connection to the impacted host. Realm reports apply to realm-routed requests for a specific realm as indicated in the Destination-Realm AVP. Reporting nodes are responsible for determining the need for a reduction of traffic. The method for making this determination is implementation specific and depend on the type of overload report being generated. A host report, for instance, will generally be generated by tracking utilization of resources required by the host to handle transactions for the the Diameter application. A realm report will generally impact the traffic sent to multiple hosts and, as such, will typically require tracking the capacity of the servers able to handle realm-routed requests for the application. Once a reporting node determines the need for a reduction in traffic, it uses the DOIC defined AVPs to report on the condition. These AVPs are included in answer messages sent or relayed by the reporting node. The reporting node indicates the overload abatement algorithm that is to be used to handle the traffic reduction in the OC- Supported-Features AVP. The OC-OLR AVP is used to communicate information about the requested reduction. Reacting nodes, upon receipt of an overload report, are responsible for applying the abatement algorithm to traffic impacted by the overload report. The method used for that abatement is dependent on the abatement algorithm. The loss abatement algorithm is defined in this document (Section 5). Other abatement algorithms can be defined in extensions to the DOIC solutions. Korhonen, et al. Expires April 12, 2015 [Page 9] Internet-Draft DOIC October 2014 As the conditions that lead to the generation of the overload report change the reporting node can send new overload reports requesting greater reduction if the condition gets worse or less reduction if the condition improves. The reporting node sends an overload report with a duration of zero to indicate that the overlaod condition has ended and use of the abatement algorithm is no longer needed. The reacting node also determines when the overload report expires based on the OC-Validaty-Duration AVP in the overload report and stops applying the abatement algorithm when the report expires. 3.4. DOIC Extensibility (Non normative) The DOIC solutions is designed to be extensible. This extensibility is based on existing Diameter based extensibility mechanisms. There are multiple categories of extensions that are expected. This includes the definition of new overload abatement algorithms, the definition of new report types and new definitions of the scope of messages impacted by an overload report. The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes to communicate supported features. The specific features supported by the DOIC node are indicated in the OC-Feature-Vector AVP. DOIC extensions must define new values for the OC-Feature-Vector AVP. DOIC extensions also have the ability to add new AVPs to the OC- Supported-Features AVP, if additional information about the new feature is required to be communicate. Overload abatement algorithms use the OC-OLR AVP to communicate overload occurances. This AVP can also be extended to add new AVPs allowing a reporting nodes to communicate additional information about handling an overload condition. If necessary, new extensions can also define new top level AVPs. It is, however, recommended that DOIC extensions use the OC-Supported- Features and OC-OLR to carry all DOIC related AVPs. 3.5. Simplified Example Architecture (Non normative) Figure 1 illustrates the simplified architecture for Diameter overload information conveyance. Korhonen, et al. Expires April 12, 2015 [Page 10] Internet-Draft DOIC October 2014 Realm X Same or other Realms <--------------------------------------> <----------------------> +--^-----+ : (optional) : |Diameter| : : |Server A|--+ .--. : +---^----+ : .--. +--------+ | _( `. : |Diameter| : _( `. +---^----+ +--( )--:-| Agent |-:--( )--|Diameter| +--------+ | ( ` . ) ) : +-----^--+ : ( ` . ) ) | Client | |Diameter|--+ `--(___.-' : : `--(___.-' +-----^--+ |Server B| : : +---^----+ : : End-to-end Overload Indication 1) <-----------------------------------------------> Diameter Application Y Overload Indication A Overload Indication A' 2) <----------------------> <----------------------> standard base protocol standard base protocol Figure 1: Simplified architecture choices for overload indication delivery In Figure 1, the Diameter overload indication can be conveyed (1) end-to-end between servers and clients or (2) between servers and Diameter agent inside the realm and then between the Diameter agent and the clients when the Diameter agent acting as back-to-back-agent for DOIC purposes. 3.6. Considerations for Applications Integrating the DOIC Solution (Non normative) THis section outlines considerations to be taken into account when integrating the DOIC solution into Diameter applications. 3.6.1. Application Classification (Non normative) The following is a classification of Diameter applications and requests. This discussion is meant to document factors that play into decisions made by the Diameter identity responsible for handling overload reports. Section 8.1 of [RFC6733] defines two state machines that imply two types of applications, session-less and session-based applications. Korhonen, et al. Expires April 12, 2015 [Page 11] Internet-Draft DOIC October 2014 The primary difference between these types of applications is the lifetime of Session-Ids. For session-based applications, the Session-Id is used to tie multiple requests into a single session. In session-less applications, the lifetime of the Session-Id is a single Diameter transaction, i.e. the session is implicitly terminated after a single Diameter transaction and a new Session-Id is generated for each Diameter request. For the purposes of this discussion, session-less applications are further divided into two types of applications: Stateless applications: Requests within a stateless application have no relationship to each other. The 3GPP defined S13 application is an example of a stateless application [S13], --> where only a Diameter command is defined between a client and a server and no state is maintained between two consecutive transactions. Pseudo-session applications: Applications that do not rely on the Session-Id AVP for correlation of application messages related to the same session but use other session-related information in the Diameter requests for this purpose. The 3GPP defined Cx application [Cx] is an example of a pseudo-session application. The Credit-Control application defined in [RFC4006] is an example of a Diameter session-based application. The handling of overload reports must take the type of application into consideration, as discussed in Section 3.6.2. 3.6.2. Application Type Overload Implications (Non normative) This section discusses considerations for mitigating overload reported by a Diameter entity. This discussion focuses on the type of application. Section 3.6.3 discusses considerations for handling various request types when the target server is known to be in an overloaded state. These discussions assume that the strategy for mitigating the reported overload is to reduce the overall workload sent to the overloaded entity. The concept of applying overload treatment to requests targeted for an overloaded Diameter entity is inherent to Korhonen, et al. Expires April 12, 2015 [Page 12] Internet-Draft DOIC October 2014 this discussion. The method used to reduce offered load is not specified here but could include routing requests to another Diameter entity known to be able to handle them, or it could mean rejecting certain requests. For a Diameter agent, rejecting requests will usually mean generating appropriate Diameter error responses. For a Diameter client, rejecting requests will depend upon the application. For example, it could mean giving an indication to the entity requesting the Diameter service that the network is busy and to try again later. Stateless applications: By definition there is no relationship between individual requests in a stateless application. As a result, when a request is sent or relayed to an overloaded Diameter entity - either a Diameter Server or a Diameter Agent - the sending or relaying entity can choose to apply the overload treatment to any request targeted for the overloaded entity. Pseudo-session applications: For pseudo-session applications, there is an implied ordering of requests. As a result, decisions about which requests towards an overloaded entity to reject could take the command code of the request into consideration. This generally means that transactions later in the sequence of transactions should be given more favorable treatment than messages earlier in the sequence. This is because more work has already been done by the Diameter network for those transactions that occur later in the sequence. Rejecting them could result in increasing the load on the network as the transactions earlier in the sequence might also need to be repeated. Session-based applications: Overload handling for session-based applications must take into consideration the work load associated with setting up and maintaining a session. As such, the entity sending requests towards an overloaded Diameter entity for a session-based application might tend to reject new session requests prior to rejecting intra-session requests. In addition, session ending requests might be given a lower probability of being rejected as rejecting session ending requests could result in session status being out of sync between the Diameter clients and servers. Application designers that would decide to reject mid-session requests will need to consider whether the rejection invalidates the session and any resulting session clean-up procedures. Korhonen, et al. Expires April 12, 2015 [Page 13] Internet-Draft DOIC October 2014 3.6.3. Request Transaction Classification (Non normative) Independent Request: An independent request is not correlated to any other requests and, as such, the lifetime of the session-id is constrained to an individual transaction. Session-Initiating Request: A session-initiating request is the initial message that establishes a Diameter session. The ACR message defined in [RFC6733] is an example of a session-initiating request. Correlated Session-Initiating Request: There are cases when multiple session-initiated requests must be correlated and managed by the same Diameter server. It is notably the case in the 3GPP PCC architecture [PCC], where multiple apparently independent Diameter application sessions are actually correlated and must be handled by the same Diameter server. Intra-Session Request: An intra session request is a request that uses the same Session- Id than the one used in a previous request. An intra session request generally needs to be delivered to the server that handled the session creating request for the session. The STR message defined in [RFC6733] is an example of an intra-session requests. Pseudo-Session Requests: Pseudo-session requests are independent requests and do not use the same Session-Id but are correlated by other session-related information contained in the request. There exists Diameter applications that define an expected ordering of transactions. This sequencing of independent transactions results in a pseudo session. The AIR, MAR and SAR requests in the 3GPP defined Cx [Cx] application are examples of pseudo-session requests. 3.6.4. Request Type Overload Implications (Non normative) The request classes identified in Section 3.6.3 have implications on decisions about which requests should be throttled first. The following list of request treatment regarding throttling is provided as guidelines for application designers when implementing the Diameter overload control mechanism described in this document. The Korhonen, et al. Expires April 12, 2015 [Page 14] Internet-Draft DOIC October 2014 exact behavior regarding throttling is a matter of local policy, unless specifically defined for the application. Independent requests: Independent requests can be given equal treatment when making throttling decisions. Session-initiating requests: Session-initiating requests represent more work than independent or intra-session requests. Moreover, session-initiating requests are typically followed by other session-related requests. As such, as the main objective of the overload control is to reduce the total number of requests sent to the overloaded entity, throttling decisions might favor allowing intra-session requests over session-initiating requests. Individual session-initiating requests can be given equal treatment when making throttling decisions. Correlated session-initiating requests: A Request that results in a new binding, where the binding is used for routing of subsequent session-initiating requests to the same server, represents more work load than other requests. As such, these requests might be throttled more frequently than other request types. Pseudo-session requests: Throttling decisions for pseudo-session requests can take into consideration where individual requests fit into the overall sequence of requests within the pseudo session. Requests that are earlier in the sequence might be throttled more aggressively than requests that occur later in the sequence. Intra-session requests There are two classes of intra-sessions requests. The first class consists of requests that terminate a session. The second one contains the set of requests that are used by the Diameter client and server to maintain the ongoing session state. Session terminating requests should be throttled less aggressively in order to gracefully terminate sessions, allow clean-up of the related resources (e.g. session state) and get rid of the need for other intra-session requests, reducing the session management impact on the overloaded entity. The default handling of other intra-session requests might be to treat them equally when making Korhonen, et al. Expires April 12, 2015 [Page 15] Internet-Draft DOIC October 2014 throttling decisions. There might also be application level considerations whether some request types are favored over others. 4. Solution Procedures (Normative) This section outlines the normative behavior associated with the DOIC solution. 4.1. Capability Announcement (Normative) This section defines DOIC Capability Announcement (DCA) behavior. The DCA procedures are used to indicate support for DOIC and support for DOIC features. The DOIC features include overload abatement algorithms supported. It might also include new report types or other extensions documented in the future. Diameter nodes indicate support for DOIC by including the OC- Supported-Features AVP in messages sent or handled by the node. Diameter agents that support DOIC MUST ensure that all messages have the OC-Supporting-Features AVP. If a message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP. If the message already has the AVP then the agent either leaves it unchanged in the relayed message or modifies it to reflect a mixed set of DOIC features. 4.1.1. Reacting Node Behavior (Normative) A reacting node MUST include the OC-Supported-Features AVP in all request messages. A reacting node MUST include the OC-Feature-Vector AVP with an indication of the loss algorithm. A reacting node SHOULD indicate support for all other DOIC features it supports. An OC-Supported-Features AVP in answer messages indicates there is a reporting node for the transaction. The reacting node MAY take action based on the features indicated in the OC-Feature-Vector AVP. Note that the loss abatement algorithm is the only feature described in this document and it does not require action to be taken by the reacting node except when the answer message also has an overload report. This behavior is described in Section 4.2 and Section 5. Korhonen, et al. Expires April 12, 2015 [Page 16] Internet-Draft DOIC October 2014 4.1.2. Reporting Node Behavior (Normative) Upon receipt of a request message, a reporting node determines if there is a reacting node for the transaction based on the presence of the OC-Supported-Features AVP. Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality supported by reacting node(s). The reporting node then acts accordingly for the subsequent answer messages it initiates. If the reqeust message contains an OC-Supported-Features AVP then the reporting node MUST include the OC-Supported-Features AVP in the answer message for that transaction. The reporting node MUST indicate support for one and only one abatement algorithm in the OC-Feature-Vector AVP. The abatement algorithm included MUST be from the set of abatement algorithms contained in the request messages OC-Supported-Features AVP. The abatement algorithm included indicates the abatement algorithm the reporting node wants the reacting node to use when the reporting node enters an overload condition. The reporting node MUST NOT change the selected algorithm during a period of time that it is in an overload condition and, as a result, is sending OC-OLR AVPs in answer messages. The reporting node SHOULD indicate support for other DOIC features it supports and that apply to the transaction. Note that not all DOIC features will apply to all Diameter applications or deployment scenarios. The features included in the OC-Feature-Vector AVP is based on local reporting node policy. The reporting node MUST NOT include the OC-Supported-Features AVP, OC-OLR AVP or any other overload control AVPs defined in extension drafts in response messages for transactions where the request message does not include the OC-Supported-Features AVP. Lack of the OC-Supported-Features AVP in the request message indicates that there is no reacting node for the transaction. An agent MAY modify the OC-Supported-Features AVP carried in answer messages. Korhonen, et al. Expires April 12, 2015 [Page 17] Internet-Draft DOIC October 2014 4.1.3. Agent Behavior (Normative) Editor's note -- Need to add this section. 4.2. Overload Report Processing (Normative) 4.2.1. Overload Control State (Normative) Both reacting and reporting nodes maintain an overload control state (OCS) for active overload reports. 4.2.1.1. Overload Control State for Reacting Nodes A reacting node maintains the following OCS per supported Diameter application: o A host-type Overload Control State for each Destination-Host towards which it sends host-type requests and o A realm-type Overload Control State for each Destination-Realm towards which it sends realm-type requests. A host-type Overload Control State may be identified by the pair of Application-Id and Destination-Host. A realm-type Overload Control State may be identified by the pair of Application-Id and Destination-Realm. The host-type/realm-type Overload Control State for a given pair of Application and Destination-Host / Destination- Realm could include the following information: o Sequence number (as received in OC-OLR) o Time of expiry (deviated from validity duration as received in OC- OLR and time of reception) o Selected Abatement Algorithm (as received in OC-Supported- Features) o Algorithm specific input data (as received within OC-OLR, e.g. Reduction Percentage for Loss) 4.2.1.2. Overload Control States for Reporting Nodes A reporting node maintains per supported Diameter application and per supported (and eventually selected) Abatement Algorithm an Overload Control State. An Overload Control State may be identified by the pair of Application-Id and supported Abatement Algorithm. Korhonen, et al. Expires April 12, 2015 [Page 18] Internet-Draft DOIC October 2014 The Overload Control State for a given pair of Application and Abatement Algorithm could include the information: o Sequence number o Validity Duration and Expiry Time o Algorithm specific input data (e.g. Reduction Percentage for Loss) Overload Control States for reporting nodes containing a validity duration of 0 sec. should not expire before any previously sent (stale) OLR has timed out at any reacting node. Editor's note: This statement is unclear and contradictory with other statements. A validity timer of zero seconds indicates that the overload condition has ended and abatement is no longer requested. 4.2.1.3. Maintaining Overload Control State Reacting nodes create a host-type OCS identified by OCS-Id = (app- id,host-id) when receiving an answer message of application app-id containing an Orig-Host of host-id and a host-type OC-OLR AVP unless such host-type OCS already exists. Reacting nodes create a realm-type OCS identified by OCS-Id = (app- id,realm-id) when receiving an answer message of application app-id containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP unless such realm type OCS already exists. Reacting nodes delete an OCS when it expires (i.e. when current time minus reception time is greater than validity duration). Editor's note: Reacting nodes also delete on OCS with an updated OLR is received with a validity duration of zero. Reacting nodes update the host-type OCS identified by OCS-Id = (app- id,host-id) when receiving an answer message of application app-id containing an Orig-Host of host-id and a host-type OC-OLR AVP with a sequence number higher than the stored sequence number. Reacting nodes update the realm-type OCS identified by OCS-Id = (app- id,realm-id) when receiving an answer message of application app-id containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP with a sequence number higher than the stored sequence number. Korhonen, et al. Expires April 12, 2015 [Page 19] Internet-Draft DOIC October 2014 Reacting nodes do not delete an OCS when receiving an answer message that does not contain an OC-OLR AVP (i.e. absence of OLR means "no change"). Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a request of application app-id containing an OC- Supported-Features AVP indicating support of the Abatement Algorithm Alg (which the reporting node selects) while being overloaded, unless such OCS already exists. Reporting nodes delete an OCS when it expires. Editor's note: Reporting nodes should send updated overload reports with a validity duration of zero for a period of time after an OCS expires or is removed due to the overload condition ending. Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the need to modify the requested amount of application app-id traffic reduction. 4.2.2. Reacting Node Behavior (Normative) Once a reacting node receives an OC-OLR AVP from a reporting node, it applies traffic abatement based on the selected algorithm with the reporting node and the current overload condition. The reacting node learns the reporting node supported abatement algorithms directly from the received answer message containing the OC-Supported-Features AVP. The received OC-Supported-Features AVP does not change the existing overload condition and/or traffic abatement algorithm settings if the OC-Sequence-Number AVP contains a value that is equal to the previously received/recorded value. If the OC-Supported-Features AVP is received for the first time for the reporting node or the OC- Sequence-Number AVP value is less than the previously received/ recorded value (and is outside the valid overflow window), then the sequence number is stale (e.g. an intentional or unintentional replay) and SHOULD be silently discarded. As described in Section 6.3, the OC-OLR AVP contains the necessary information for the overload condition on the reporting node. From the OC-Report-Type AVP contained in the OC-OLR AVP, the reacting node learns whether the overload condition report concerns a specific host (as identified by the Origin-Host AVP of the answer message containing the OC-OLR AVP) or the entire realm (as identified by the Origin-Realm AVP of the answer message containing the OC-OLR AVP). The reacting node learns the Diameter application to which the Korhonen, et al. Expires April 12, 2015 [Page 20] Internet-Draft DOIC October 2014 overload report applies from the Application-ID of the answer message containing the OC-OLR AVP. The reacting node MUST use this information as an input for its traffic abatement algorithm. The idea is that the reacting node applies different handling of the traffic abatement, whether sent request messages are targeted to a specific host (identified by the Diameter-Host AVP in the request) or to any host in a realm (when only the Destination-Realm AVP is present in the request). Note that future specifications MAY define new OC-Report-Type AVP values that imply different handling of the OC-OLR AVP. For example, in a form of new additional AVPs inside the Grouped OC-OLR AVP that would define report target in a finer granularity than just a host. Editor's note: The above behavior for Realm reports is inconsistent with the definition of realm reports in section Section 6.6. If the OC-OLR AVP is received for the first time, the reacting node MUST create overload control state associated with the related realm or a specific host in the realm identified in the message carrying the OC-OLR AVP, as described in Section 4.2.1. If the value of the OC-Sequence-Number AVP contained in the received OC-OLR AVP is equal to or less than the value stored in an existing overload control state, the received OC-OLR AVP SHOULD be silently discarded. If the value of the OC-Sequence-Number AVP contained in the received OC-OLR AVP is greater than the value stored in an existing overload control state or there is no previously recorded sequence number, the reacting node MUST update the overload control state associated with the realm or the specific node in the realm. When an overload control state is created or updated, the reacting node MUST apply the traffic abatement requested in the OC-OLR AVP using the algorithm announced in the OC-Supported-Features AVP contained in the received answer message along with the OC-OLR AVP. The validity duration of the overload information contained in the OC-OLR AVP is either explicitly indicated in the OC-Validity-Duration AVP or is implicitly equals to the default value (5 seconds) if the OC-Validity-Duration AVP is absent. The reacting node MUST maintain the validity duration in the overload control state. Once the validity duration times out, the reacting node MUST assume the overload condition reported in a previous OC-OLR AVP has ended. A value of zero ("0") received in the OC-Validity-Duration in an updated overload report indicates that the overload condition has ended and that the overload state is no longer valid. Korhonen, et al. Expires April 12, 2015 [Page 21] Internet-Draft DOIC October 2014 In the case that the validity duration expires or is explicitly signaled as being no longer valid the state associated with the overload report MUST be removed and any abatement associated with the overload report MUST be ended in a controlled fashion. After removing the overload state the sequence number MUST NOT be used for future comparisons of sequence numbers. 4.2.3. Reporting Node Behavior (Normative) A reporting node is a Diameter node inserting an OC-OLR AVP in a Diameter message in order to inform a reacting node about an overload condition and request Diameter traffic abatement. The operation on the reporting node is straight forward. The reporting node learns the capabilities of the reacting node when it receives the OC-Supported-Features AVP as part of any Diameter request message. If the reporting node shares at least one common feature with the reacting node, then the DOIC can be enabled between these DOIC nodes See Section 4.1 for further discussion on the capability and feature announcement. When a traffic reduction is required due to an overload condition and the overload control solution is supported by the sender of the Diameter request, the reporting node MUST include an OC-Supported- Features AVP and an OC-OLR AVP in the corresponding Diameter answer. The OC-OLR AVP contains the required traffic reduction and the OC- Supported-Features AVP indicates the traffic abatement algorithm to apply. This algorithm MUST be one of the algorithms advertised by the request sender. A reporting node MAY rely on the OC-Validity-Duration AVP values for the implicit overload control state cleanup on the reacting node. However, it is RECOMMENDED that the reporting node always explicitly indicates the end of a overload condition. The reporting node SHOULD indicate the end of an overload occurrence by sending a new OLR with OC-Validity-Duration set to a value of zero ("0"). The reporting node SHOULD insure that all reacting nodes receive the updated overload report. 4.2.4. Agent Behavior (Normative) Editor's note -- Need to add this section. Korhonen, et al. Expires April 12, 2015 [Page 22] Internet-Draft DOIC October 2014 4.3. Protocol Extensibility (Normative) The overload control solution can be extended, e.g. with new traffic abatement algorithms, new report types or other new functionality. When defining a new extension a new feature bit MUST be defined for the OC-Feature-Vector. This feature bit is used to communicate support for the new feature. The extention may also define new AVPs for use in DOIC Capability Anouncement and for use in DOIC Overload reporting. These new AVP should be defined to be extensions to the OC-Supported-Features and OC-OLR AVPs defined in this document. It should be noted that [RFC6733] defined Grouped AVP extension mechanisms apply. This allows, for example, defining a new feature that is mandatory to be understood even when piggybacked on an existing applications. More specifically, the sub-AVPs inside the OC-Supported-Features and OC-OLR AVP MAY have the M-bit set. However, when overload control AVPs are piggybacked on top of an existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED. The handling of feature bits in the OC-Feature-Vector AVP that are not associated with overload abatement algorithms MUST be specified by the extensions that define the features. When defining new report type values, the corresponding specification MUST define the semantics of the new report types and how they affect the OC-OLR AVP handling. The specification MUST also reserve a corresponding new feature, see the OC-Supported-Features and OC- Feature-Vector AVPs. The OC-OLR AVP can be expanded with optional sub-AVPs only if a legacy implementation can safely ignore them without breaking backward compatibility for the given OC-Report-Type AVP value implied report handling semantics. If the new sub-AVPs imply new semantics for handling the indicated report type, then a new OC-Report-Type AVP value MUST be defined. New features (feature bits in the OC-Feature-Vector AVP) and report types (in the OC-Report-Type AVP) MUST be registered with IANA. As with any Diameter specification, new AVPs MUST also be registered with IANA. See Section 8 for the required procedures. Korhonen, et al. Expires April 12, 2015 [Page 23] Internet-Draft DOIC October 2014 5. Loss Algorithm (Normative) This section documents the Diameter overload loss abatement algorithm. 5.1. Overview (Non normative) The DOIC specification supports the ability for multiple overload abatement algorithms to be specified. The abatement algorithm used for any instance of overload is determined by the Diameter Overload Capability Announcement process documented in Section 4.1. The loss algorithm described in this section is the default algorithm that must be supported by all Diameter nodes that support DOIC. The loss algorithm is designed to be a straightforward and stateless overload abatement algorithm. It is used by reporting nodes to request a percentage reduction in the amount of traffic sent. The traffic impacted by the requested reduction depends on the type of overload report. Reporting nodes use a strategy of applying abatement logic to the requested percentage of request messages sent (or handled in the case of agents) by the reacting node that are impacted by the overload report. From a conceptual level, the logic at the reacting node could be outlined as follows. In this discussion assume that the reacting node is also the sending node. 1. An overload report is received and the associated overload state is saved by the reacting node. 2. A new Diameter request is generated by the application running on the reacting node. 3. The reacting node determines that an active overload report applies to the request. 4. The reacting node determines if abatement should be applied to the request. One approach that could be taken would be to select a random number between 1 and 100. If the random number is less than the indicated reduction percentage then the request is given abatement treatment, otherwise the request is given normal routing treatment. Korhonen, et al. Expires April 12, 2015 [Page 24] Internet-Draft DOIC October 2014 5.2. Use of OC-Reduction-Percentage AVP A reporting node using the loss algorithm must use the OC-Reduction- Percentage AVP (Section 6.7 to indicated the desired percentage of traffic reduction.) Editor's note: The above duplicates what is in the OC-Reduction- Percentage AVP section can probably be removed. 5.3. Reporting Node Behavior (Normative) The method a reporting nodes uses to determine the amount of traffic reduction required to address an overload condition is an implementation decision. When a reporting node that has selected the loss abatement algorithm determines the need to request a traffic reduction it must include an OC-OLR AVP in all response messages. The reporting node must indicate a percentage reduction in the OC- Reduction-Percentage AVP. The reporting node may change the reduction percentage in subsequent overload reports. When doing so the reporting node must conform to overload report handing specified in Section 4.2.3. When the reporting node determines it no longer needs a reduction in traffic the reporting node should send an overload report indicating the overload report is no longer valid, as specified in Section 4.2.3. 5.4. Reacting Node Behavior (Normative) The method a reacting node uses to determine which request messages are given abatement treatment is an implementation decision. When receiving an OC-OLR in an answer message where the algorithm indicated in the OC-Supported-Features AVP is the loss algorithm, the reacting node must attempt to apply abatement treatment to the requested percentage of request messages sent. Note: the loss algorithm is a stateless algorithm. As a result, the reacting node does not guarantee that there will be an absolute reduction in traffic sent. Rather, it guarantees that the requested percentage of new requests will be given abatement treatment. Korhonen, et al. Expires April 12, 2015 [Page 25] Internet-Draft DOIC October 2014 If reacting node comes out of the 100 percent traffic reduction as a result of the overload report timing out, the following concerns are RECOMMENDED to be applied. The reacting node sending the traffic should be conservative and, for example, first send "probe" messages to learn the overload condition of the overloaded node before converging to any traffic amount/rate decided by the sender. Similar concerns apply in all cases when the overload report times out unless the previous overload report stated 0 percent reduction. Editor's note: Need to add additional guidance to slowly increase the rate of traffic sent to avoid a sudden spike in traffic, as the spike in traffic could result in oscillation of the need for overload control. If the reacting node does not receive a an OLR in messages sent to the formally overloaded node then the reacting node should slowly increase the rate of traffic sent to the overloaded node. It is suggested that the reacting node decrease the amount of traffic given abatement treatment by 20% each second until the reduction is completely removed and no traffic is given abatement treatment. The goal of this behavior is to reduce the probability of overload condition thrashing where an immediate transition from 100% reduction to 0% reduction results in the reporting node moving quickly back into an overload condition. 6. Attribute Value Pairs (Normative) This section describes the encoding and semantics of the Diameter Overload Indication Attribute Value Pairs (AVPs) defined in this document. When added to existing commands, both OC-Feature-Vector and OC-OLR AVPs SHOULD have the M-bit flag cleared to avoid backward compatibility issues. A new application specification can incorporate the overload control mechanism specified in this document by making it mandatory to implement for the application and referencing this specification normatively. In such a case, the OC-Feature-Vector and OC-OLR AVPs reused in newly defined Diameter applications SHOULD have the M-bit flag set. However, it is the responsibility of the Diameter application designers to define how overload control mechanisms works on that application. Korhonen, et al. Expires April 12, 2015 [Page 26] Internet-Draft DOIC October 2014 6.1. OC-Supported-Features AVP The OC-Supported-Features AVP (AVP code TBD1) is type of Grouped and serves for two purposes. First, it announces a node's support for the DOIC in general. Second, it contains the description of the supported DOIC features of the sending node. The OC-Supported- Features AVP MUST be included in every Diameter message a DOIC supporting node sends. OC-Supported-Features ::= < AVP Header: TBD1 > [ OC-Feature-Vector ] * [ AVP ] The OC-Feature-Vector sub-AVP is used to announce the DOIC features supported by the DOIC node, in the form of a flag bits field in which each bit announces one feature or capability supported by the node (see Section 6.2). The absence of the OC-Feature-Vector AVP indicates that only the default traffic abatement algorithm described in this specification is supported. A reacting node includes this AVP to indicate its capabilities to a reporting node. For example, the reacting node may indicate which (future defined) traffic abatement algorithms it supports in addition to the default. During the message exchange the DOIC nodes express their common set of supported capabilities. The reacting node includes the OC- Supported-Features AVP that announces what it supports. The reporting node that sends the answer also includes the OC-Supported- Features AVP that describes the capabilities it supports. The set of capabilities advertised by the reporting node depends on local policies. At least one of the announced capabilities MUST match. If there is no single matching capability the reacting node MUST act as if it does not implement DOIC and cease inserting any DOIC related AVPs into any Diameter messages with this specific reacting node. Editor's note: The last sentence conflicts with the last sentence two paragraphs up. In reality, there will always be at least one matching capability as all nodes supporting DOIC must support the loss algorithm. Suggest removing the last sentence. 6.2. OC-Feature-Vector AVP The OC-Feature-Vector AVP (AVP code TBD6) is type of Unsigned64 and contains a 64 bit flags field of announced capabilities of a DOIC node. The value of zero (0) is reserved. Korhonen, et al. Expires April 12, 2015 [Page 27] Internet-Draft DOIC October 2014 The following capabilities are defined in this document: OLR_DEFAULT_ALGO (0x0000000000000001) When this flag is set by the DOIC node it means that the default traffic abatement (loss) algorithm is supported. 6.3. OC-OLR AVP The OC-OLR AVP (AVP code TBD2) is type of Grouped and contains the necessary information to convey an overload report. The OC-OLR AVP does not explicitly contain all information needed by the reacting node to decide whether a subsequent request must undergo a throttling process with the received reduction percentage. The value of the OC- Report-Type AVP within the OC-OLR AVP indicates which implicit information is relevant for this decision (see Section 6.6). The application the OC-OLR AVP applies to is the same as the Application- Id found in the Diameter message header. The identity the OC-OLR AVP concerns is determined from the Origin-Host AVP (and Origin-Realm AVP as well) found from the encapsulating Diameter command. The OC-OLR AVP is intended to be sent only by a reporting node. OC-OLR ::= < AVP Header: TBD2 > < OC-Sequence-Number > < OC-Report-Type > [ OC-Reduction-Percentage ] [ OC-Validity-Duration ] * [ AVP ] The OC-Validity-Duration AVP indicates the validity time of the overload report associated with a specific sequence number, measured after reception of the OC-OLR AVP. The validity time MUST NOT be updated after reception of subsequent OC-OLR AVPs with the same sequence number. The default value for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. Note that if a Diameter command were to contain multiple OC-OLR AVPs they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs with unknown values SHOULD be silently discarded and the event SHOULD be logged. Editor's note: Need to specify what happens when two reports of the same type are received. Korhonen, et al. Expires April 12, 2015 [Page 28] Internet-Draft DOIC October 2014 6.4. OC-Sequence-Number AVP The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64. Its usage in the context of overload control is described in Section 4.2. From the functionality point of view, the OC-Sequence-Number AVP MUST be used as a non-volatile increasing counter between two DOIC nodes. The sequence number is only required to be unique between two DOIC nodes. Sequence numbers are treated in a uni-directional manner, i.e. two sequence numbers on each direction between two DOIC nodes are not related or correlated. When generating sequence numbers, the new sequence number MUST be greater than any sequence number in an active overload report previously sent by the reporting node. This property MUST hold over a reboot of the reporting node. 6.5. OC-Validity-Duration AVP The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and indicates in seconds the validity time of the overload report. The number of seconds is measured after reception of the first OC-OLR AVP with a given value of OC-Sequence-Number AVP. The default value for the OC-Validity-Duration AVP is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. Validity duration with values above 86400 (i.e.; 24 hours) MUST NOT be used. Invalid duration values are treated as if the OC-Validity-Duration AVP were not present and result in the default value being used. A timeout of the overload report has specific concerns that need to be taken into account by the DOIC node acting on the earlier received overload report(s). Section 6.7 discusses the impacts of timeout in the scope of the traffic abatement algorithms. When a reporting node has recovered from overload, it SHOULD invalidate any existing overload reports in a timely matter. This can be achieved by sending an updated overload report (meaning the OLR contains a new sequence number) with the OC-Validity-Duration AVP value set to zero ("0"). If the overload report is about to expire naturally, the reporting node MAY choose to simply let it do so. A reacting node MUST invalidate and remove an overload report that expires without an explicit overload report containing an OC- Validity-Duration value set to zero ("0"). Korhonen, et al. Expires April 12, 2015 [Page 29] Internet-Draft DOIC October 2014 6.6. OC-Report-Type AVP The OC-Report-Type AVP (AVP code TBD5) is type of Enumerated. The value of the AVP describes what the overload report concerns. The following values are initially defined: 0 A host report. The overload treatment should apply to requests for which all of the following conditions are true: Either the Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP; or the Destination-Host is not present in the request but the value of peer identity associated with the connection used to send the request matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. 1 A realm report. The overload treatment should apply to requests for which all of the following conditions are true: The Destination-Host AVP is absent in the request. The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. Editor's note: There is still an open issue on the definition of Realm reports and whether what report types should be supported. There is consensus that host reports should be supported. There is discussion on Realm reports and Realm-Routed-Request reports. The above definition applies to Realm-Routed-Request reports where Realm reports are defined to apply to all requests that match the realm, independent of the presence, absence or value of the Destination-Host AVP. Korhonen, et al. Expires April 12, 2015 [Page 30] Internet-Draft DOIC October 2014 The default value of the OC-Report-Type AVP is 0 (i.e. the host report). The OC-Report-Type AVP is envisioned to be useful for situations where a reacting node needs to apply different overload treatments for different "types" of overload. For example, the reacting node(s) might need to throttle differently requests sent to a specific server (identified by the Destination-Host AVP in the request) and requests that can be handled by any server in a realm. The example in Appendix B.1 illustrates this usage. 6.7. OC-Reduction-Percentage AVP The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32 and describes the percentage of the traffic that the sender is requested to reduce, compared to what it otherwise would send. The OC-Reduction-Percentage AVP applies to the default (loss) algorithm specified in this specification. However, the AVP can be reused for future abatement algorithms, if its semantics fit into the new algorithm. The value of the Reduction-Percentage AVP is between zero (0) and one hundred (100). Values greater than 100 are ignored. The value of 100 means that all traffic is to be throttled, i.e. the reporting node is under a severe load and ceases to process any new messages. The value of 0 means that the reporting node is in a stable state and has no need for the reacting node to apply any traffic abatement. The default value of the OC-Reduction-Percentage AVP is 0. When the OC-Reduction-Percentage AVP is not present in the overload report, the default value applies. 6.8. Attribute Value Pair flag rules Korhonen, et al. Expires April 12, 2015 [Page 31] Internet-Draft DOIC October 2014 +---------+ |AVP flag | |rules | +----+----+ AVP Section | |MUST| Attribute Name Code Defined Value Type |MUST| NOT| +--------------------------------------------------+----+----+ |OC-Supported-Features TBD1 x.x Grouped | | V | +--------------------------------------------------+----+----+ |OC-OLR TBD2 x.x Grouped | | V | +--------------------------------------------------+----+----+ |OC-Sequence-Number TBD3 x.x Unsigned64 | | V | +--------------------------------------------------+----+----+ |OC-Validity-Duration TBD4 x.x Unsigned32 | | V | +--------------------------------------------------+----+----+ |OC-Report-Type TBD5 x.x Enumerated | | V | +--------------------------------------------------+----+----+ |OC-Reduction | | | | -Percentage TBD8 x.x Unsigned32 | | V | +--------------------------------------------------+----+----+ |OC-Feature-Vector TBD6 x.x Unsigned64 | | V | +--------------------------------------------------+----+----+ As described in the Diameter base protocol [RFC6733], the M-bit setting for a given AVP is relevant to an application and each command within that application that includes the AVP. The Diameter overload control AVPs SHOULD always be sent with the M-bit cleared when used within existing Diameter applications to avoid backward compatibility issues. Otherwise, when reused in newly defined Diameter applications, the DOC related AVPs SHOULD have the M-bit set. 7. Error Response Codes Editor's note: This section depends on resolution of issue #27. 8. IANA Considerations 8.1. AVP codes New AVPs defined by this specification are listed in Section 6. All AVP codes allocated from the 'Authentication, Authorization, and Accounting (AAA) Parameters' AVP Codes registry. Korhonen, et al. Expires April 12, 2015 [Page 32] Internet-Draft DOIC October 2014 8.2. New registries Three new registries are needed under the 'Authentication, Authorization, and Accounting (AAA) Parameters' registry. Section 6.2 defines a new "Overload Control Feature Vector" registry including the initial assignments. New values can be added into the registry using the Specification Required policy [RFC5226]. See Section 6.2 for the initial assignment in the registry. Section 6.6 defines a new "Overload Report Type" registry with its initial assignments. New types can be added using the Specification Required policy [RFC5226]. 9. Security Considerations This mechanism gives Diameter nodes the ability to request that downstream nodes send fewer Diameter requests. Nodes do this by exchanging overload reports that directly affect this reduction. This exchange is potentially subject to multiple methods of attack, and has the potential to be used as a Denial-of-Service (DoS) attack vector. Overload reports may contain information about the topology and current status of a Diameter network. This information is potentially sensitive. Network operators may wish to control disclosure of overload reports to unauthorized parties to avoid its use for competitive intelligence or to target attacks. Diameter does not include features to provide end-to-end authentication, integrity protection, or confidentiality. This may cause complications when sending overload reports between non- adjacent nodes. 9.1. Potential Threat Modes The Diameter protocol involves transactions in the form of requests and answers exchanged between clients and servers. These clients and servers may be peers, that is,they may share a direct transport (e.g. TCP or SCTP) connection, or the messages may traverse one or more intermediaries, known as Diameter Agents. Diameter nodes use TLS, DTLS, or IPSec to authenticate peers, and to provide confidentiality and integrity protection of traffic between peers. Nodes can make authorization decisions based on the peer identities authenticated at the transport layer. When agents are involved, this presents an effectively hop-by-hop trust model. That is, a Diameter client or server can authorize an Korhonen, et al. Expires April 12, 2015 [Page 33] Internet-Draft DOIC October 2014 agent for certain actions, but it must trust that agent to make appropriate authorization decisions about its peers, and so on. Since confidentiality and integrity protection occurs at the transport layer. Agents can read, and perhaps modify, any part of a Diameter message, including an overload report. There are several ways an attacker might attempt to exploit the overload control mechanism. An unauthorized third party might inject an overload report into the network. If this third party is upstream of an agent, and that agent fails to apply proper authorization policies, downstream nodes may mistakenly trust the report. This attack is at least partially mitigated by the assumption that nodes include overload reports in Diameter answers but not in requests. This requires an attacker to have knowledge of the original request in order to construct a response. Therefore, implementations SHOULD validate that an answer containing an overload report is a properly constructed response to a pending request prior to acting on the overload report. A similar attack involves an otherwise authorized Diameter node that sends an inappropriate overload report. For example, a server for the realm "example.com" might send an overload report indicating that a competitor's realm "example.net" is overloaded. If other nodes act on the report, they may falsely believe that "example.net" is overloaded, effectively reducing that realm's capacity. Therefore, it's critical that nodes validate that an overload report received from a peer actually falls within that peer's responsibility before acting on the report or forwarding the report to other peers. For example, an overload report from an peer that applies to a realm not handled by that peer is suspect. An attacker might use the information in an overload report to assist in certain attacks. For example, an attacker could use information about current overload conditions to time a DoS attack for maximum effect, or use subsequent overload reports as a feedback mechanism to learn the results of a previous or ongoing attack. 9.2. Denial of Service Attacks Diameter overload reports can cause a node to cease sending some or all Diameter requests for an extended period. This makes them a tempting vector for DoS tacks. Furthermore, since Diameter is almost always used in support of other protocols, a DoS attack on Diameter is likely to impact those protocols as well. Therefore, Diameter nodes MUST NOT honor or forward overload reports from unauthorized or otherwise untrusted sources. Korhonen, et al. Expires April 12, 2015 [Page 34] Internet-Draft DOIC October 2014 9.3. Non-Compliant Nodes When a Diameter node sends an overload report, it cannot assume that all nodes will comply. A non-compliant node might continue to send requests with no reduction in load. Requirement 28 [RFC7068] indicates that the overload control solution cannot assume that all Diameter nodes in a network are necessarily trusted, and that malicious nodes not be allowed to take advantage of the overload control mechanism to get more than their fair share of service. In the absence of an overload control mechanism, Diameter nodes need to implement strategies to protect themselves from floods of requests, and to make sure that a disproportionate load from one source does not prevent other sources from receiving service. For example, a Diameter server might reject a certain percentage of requests from sources that exceed certain limits. Overload control can be thought of as an optimization for such strategies, where downstream nodes never send the excess requests in the first place. However, the presence of an overload control mechanism does not remove the need for these other protection strategies. 9.4. End-to End-Security Issues The lack of end-to-end security features makes it far more difficult to establish trust in overload reports that originate from non- adjacent nodes. Any agents in the message path may insert or modify overload reports. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive-trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting Diameter overload control MUST give operators the ability to select which peers are trusted to deliver overload reports, and whether they are trusted to forward overload reports from non-adjacent nodes. The lack of end-to-end confidentiality protection means that any Diameter agent in the path of an overload report can view the contents of that report. In addition to the requirement to select which peers are trusted to send overload reports, operators MUST be able to select which peers are authorized to receive reports. A node MUST not send an overload report to a peer not authorized to receive it. Furthermore, an agent MUST remove any overload reports that might have been inserted by other nodes before forwarding a Diameter message to a peer that is not authorized to receive overload reports. At the time of this writing, the DIME working group is studying requirements for adding end-to-end security Korhonen, et al. Expires April 12, 2015 [Page 35] Internet-Draft DOIC October 2014 [I-D.ietf-dime-e2e-sec-req] features to Diameter. These features, when they become available, might make it easier to establish trust in non-adjacent nodes for overload control purposes. Readers should be reminded, however, that the overload control mechanism encourages Diameter agents to modify AVPs in, or insert additional AVPs into, existing messages that are originated by other nodes. If end-to-end security is enabled, there is a risk that such modification could violate integrity protection. The details of using any future Diameter end-to-end security mechanism with overload control will require careful consideration, and are beyond the scope of this document. 10. Contributors The following people contributed substantial ideas, feedback, and discussion to this document: o Eric McMurry o Hannes Tschofenig o Ulrich Wiehe o Jean-Jacques Trottin o Maria Cruz Bartolome o Martin Dolly o Nirav Salot o Susan Shishufeng 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. Korhonen, et al. Expires April 12, 2015 [Page 36] Internet-Draft DOIC October 2014 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012. 11.2. Informative References [Cx] 3GPP, , "ETSI TS 129 229 V11.4.0", August 2013. [I-D.ietf-dime-e2e-sec-req] Tschofenig, H., Korhonen, J., Zorn, G., and K. Pillay, "Diameter AVP Level Security: Scenarios and Requirements", draft-ietf-dime-e2e-sec-req-00 (work in progress), September 2013. [PCC] 3GPP, , "ETSI TS 123 203 V11.12.0", December 2013. [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005. [RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009. [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control Requirements", RFC 7068, November 2013. [S13] 3GPP, , "ETSI TS 129 272 V11.9.0", December 2012. Appendix A. Issues left for future specifications The base solution for the overload control does not cover all possible use cases. A number of solution aspects were intentionally left for future specification and protocol work. A.1. Additional traffic abatement algorithms This specification describes only means for a simple loss based algorithm. Future algorithms can be added using the designed solution extension mechanism. The new algorithms need to be registered with IANA. See Sections 6.1 and 8 for the required IANA steps. A.2. Agent Overload This specification focuses on Diameter endpoint (server or client) overload. A separate extension will be required to outline the handling the case of agent overload. Korhonen, et al. Expires April 12, 2015 [Page 37] Internet-Draft DOIC October 2014 A.3. DIAMETER_TOO_BUSY clarifications The current [RFC6733] behavior in a case of DIAMETER_TOO_BUSY is somewhat under specified. For example, there is no information how long the specific Diameter node is willing to be unavailable. A specification updating [RFC6733] should clarify the handling of DIAMETER_TOO_BUSY from the error answer initiating Diameter node point of view and from the original request initiating Diameter node point of view. Further, the inclusion of possible additional information providing AVPs should be discussed and possible be recommended to be used. Appendix B. Examples B.1. Mix of Destination-Realm routed requests and Destination-Host routed requests Diameter allows a client to optionally select the destination server of a request, even if there are agents between the client and the server. The client does this using the Destination-Host AVP. In cases where the client does not care if a specific server receives the request, it can omit Destination-Host and route the request using the Destination-Realm and Application Id, effectively letting an agent select the server. Clients commonly send mixtures of Destination-Host and Destination- Realm routed requests. For example, in an application that uses user sessions, a client typically won't care which server handles a session-initiating requests. But once the session is initiated, the client will send all subsequent requests in that session to the same server. Therefore it would send the initial request with no Destination-Host AVP. If it receives a successful answer, the client would copy the Origin-Host value from the answer message into a Destination-Host AVP in each subsequent request in the session. An agent has very limited options in applying overload abatement to requests that contain Destination-Host AVPs. It typically cannot route the request to a different server than the one identified in Destination-Host. It's only remaining options are to throttle such requests locally, or to send an overload report back towards the client so the client can throttle the requests. The second choice is usually more efficient, since it prevents any throttled requests from being sent in the first place, and removes the agent's need to send errors back to the client for each dropped request. On the other hand, an agent has much more leeway to apply overload abatement for requests that do not contain Destination-Host AVPs. If the agent has multiple servers in its peer table for the given realm Korhonen, et al. Expires April 12, 2015 [Page 38] Internet-Draft DOIC October 2014 and application, it can route such requests to other, less overloaded servers. If the overload severity increases, the agent may reach a point where there is not sufficient capacity across all servers to handle even realm-routed requests. In this case, the realm itself can be considered overloaded. The agent may need the client to throttle realm-routed requests in addition to Destination-Host routed requests. The overload severity may be different for each server, and the severity for the realm at is likely to be different than for any specific server. Therefore, an agent may need to forward, or originate, multiple overload reports with differing ReportType and Reduction-Percentage values. Figure 2 illustrates such a mixed-routing scenario. In this example, the servers S1, S2, and S3 handle requests for the realm "realm". Any of the three can handle requests that are not part of a user session (i.e. routed by Destination-Realm). But once a session is established, all requests in that session must go to the same server. Client Agent S1 S2 S3 | | | | | |(1) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S1 | | | | | | | | | | | | | | | | | | |(2) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |S1 overloaded, returns OLR | | | | | | | | | | | | | | | | |(3) Answer (OR:realm,OH:S1,OLR:RT=DH) | |<--------| | | | | | | | | | | | | | |sees OLR,routes DR traffic to S2&S3 | | | | | | | | | | | | | | | |(4) Answer (OR:realm,OH:S1, OLR:RT=DH) | |<--------| | | | Korhonen, et al. Expires April 12, 2015 [Page 39] Internet-Draft DOIC October 2014 | | | | | | | | | | |Client throttles requests with DH:S1 | | | | | | | | | | | | | | | | |(5) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S2 | | | | | | | | | | | | | | | | | | |(6) Request (DR:realm) | | |------------------>| | | | | | | | | | | | | | | |S2 is overloaded... | | | | | | | | | | | | | | | | |(7) Answer (OH:S2, OLR:RT=DH)| | |<------------------| | | | | | | | | | | | | |Agent sees OLR, realm now overloaded | | | | | | | | | | | | | | | |(8) Answer (OR:realm,OH:S2, OLR:RT=DH, OLR: RT=R) |<--------| | | | | | | | | | | | | | |Client throttles DH:S1, DH:S2, and DR:realm | | | | | | | | | | | | | | | | | | | | | | | | | Figure 2: Mix of Destination-Host and Destination-Realm Routed Requests 1. The client sends a request with no Destination-Host AVP (that is, a Destination-Realm routed request.) Korhonen, et al. Expires April 12, 2015 [Page 40] Internet-Draft DOIC October 2014 2. The agent follows local policy to select a server from its peer table. In this case, the agent selects S2 and forwards the request. 3. S1 is overloaded. It sends a answer indicating success, but also includes an overload report. Since the overload report only applies to S1, the ReportType is "Destination-Host". 4. The agent sees the overload report, and records that S1 is overloaded by the value in the Reduction-Percentage AVP. It begins diverting the indicated percentage of realm-routed traffic from S1 to S2 and S3. Since it can't divert Destination-Host routed traffic, it forwards the overload report to the client. This effectively delegates the throttling of traffic with Destination-Host:S1 to the client. 5. The client sends another Destination-Realm routed request. 6. The agent selects S2, and forwards the request. 7. It turns out that S2 is also overloaded, perhaps due to all that traffic it took over for S1. S2 returns an successful answer containing an overload report. Since this report only applies to S2, the ReportType is "Destination-Host". 8. The agent sees that S2 is also overloaded by the value in Reduction-Percentage. This value is probably different than the value from S1's report. The agent diverts the remaining traffic to S3 as best as it can, but it calculates that the remaining capacity across all three servers is no longer sufficient to handle all of the realm-routed traffic. This means the realm itself is overloaded. The realm's overload percentage is most likely different than that for either S1 or S2. The agent forward's S2's report back to the client in the Diameter answer. Additionally, the agent generates a new report for the realm of "realm", and inserts that report into the answer. The client throttles requests with Destination-Host:S1 at one rate, requests with Destination-Host:S2 at another rate, and requests with no Destination-Host AVP at yet a third rate. (Since S3 has not indicated overload, the client does not throttle requests with Destination-Host:S3.) Appendix C. Restructuring of -02 version of the draft This section captures the initial plan for restructuring the DOIC specification from the -02 version to the new -03 version. 1. Introduction (non normative) Korhonen, et al. Expires April 12, 2015 [Page 41] Internet-Draft DOIC October 2014 -- Existing Text from section 1. -- 2. Terminology and Abbreviations (non normative) -- Existing Text from section 2. -- 3. Solution Overview (Non normative) -- Existing text from section 3. -- 3.1 Overload Control Endpoints (Non normative) -- New text leveraging text from existing section 5.1 -- 3.2 Piggybacking Principle (Non normative) -- Existing text from existing section 5.2, with enhancements -- 3.3 DOIC Capability Discovery (Non normative) -- New text leveraging text from existing section 5.3 -- 3.4 DOIC Overload Condition Reporting (Non normative) -- New text -- 3.5 DOIC Extensibility (Non normative) -- New text leveraging text from existing Section 5.4 -- 3.5 Simplified Example Architecture (Non normative) -- Existing text from section 3.1.6, with enhancements -- 3.6 Considerations for Applications Integrating the DOIC Solution (Non normative) -- New text -- 3.6.1. Application Classification (Non normative) -- Existing text from section 3.1.1 -- 3.6.2. Application Type Overload Implications (Non normative) -- Existing text from section 3.1.2 -- 3.6.3. Request Transaction Classification (Non normative) -- Existing text from section 3.1.3 -- 3.6.4. Request Type Overload Implications (Non normative) -- Existing text from section 3.1.4 -- 4. Solution Procedures (Normative) 4.1 Capability Announcement (Normative) -- Existing text from section 5.3 -- 4.1.1. Reacting Node Behavior (Normative) -- Existing text from section 5.3.1 -- 4.1.2. Reporting Node Behavior (Normative) -- Existing text from section 5.3.2 -- 4.1.3. Agent Behavior (Normative) -- Existing text from section 5.3.3 -- 4.2. Overload Report Processing (Normative) 4.2.1. Overload Control State (Normative) -- Existing text from section 5.5.1 -- 4.2.2. Reacting Node Behavior (Normative) -- Existing text from section 5.5.2 -- 4.2.3. Reporting Node Behavior (Normative) -- Existing text from section 5.5.3 -- 4.2.4. Agent Behavior (Normative) -- Existing text from section 5.5.4 -- 4.3. Protocol Extensibility (Normative) -- Existing text from section 5.4 -- 5. Loss Algorithm (Normative) Korhonen, et al. Expires April 12, 2015 [Page 42] Internet-Draft DOIC October 2014 -- New text pulling from information spread through the document -- 5.1. Overview (Non normative) -- New text pulling from information spread through the document -- 5.2. Reporting Node Behavior (Normative) -- New text pulling from information spread through the document -- 5.3. Reacting Node Behavior (Normative) -- New text pulling from information spread through the document -- 6. Attribute Value Pairs (Normative) -- Existing text from section 4. -- 6.1. OC-Supported-Features AVP -- Existing text from section 4.1 -- 6.2. OC-Feature-Vector AVP -- Existing text from section 4.2 -- 6.3. OC-OLR AVP -- Existing text from section 4.3 -- 6.4. OC-Sequence-Number AVP -- Existing text from section 4.4 -- 6.5. OC-Validity-Duration AVP -- Existing text from section 4.5 -- 6.6. OC-Report-Type AVP -- Existing text from section 4.6 -- 6.7. OC-Reduction-Percentage AVP -- Existing text from section 4.7 -- 6.8. Attribute Value Pair flag rules -- Existing text from section 4.8 -- 7. Error Response Codes -- New text based on resolution of issue -- 8. IANA Considerations -- Existing text from section 7. -- 8.1. AVP codes -- Existing text from section 7.1 -- 8.2. New registries -- Existing text from section 7.2 -- 9. Security Considerations -- Existing text from section 8. -- 9.1. Potential Threat Modes -- Existing text from section 8.1 -- 9.2. Denial of Service Attacks -- Existing text from section 8.2 -- 9.3. Non-Compliant Nodes -- Existing text from section 8.3 -- 9.4. End-to End-Security Issues -- Existing text from section 8.4 -- 10. Contributors 11. References 11.1. Normative References 11.2. Informative References Appendix A. Issues left for future specifications Korhonen, et al. Expires April 12, 2015 [Page 43] Internet-Draft DOIC October 2014 A.1. Additional traffic abatement algorithms A.2. Agent Overload A.3. DIAMETER_TOO_BUSY clarifications A.4. Per reacting node reports Appendix B. Examples B.1. Mix of Destination-Realm routed requests and Destination- Host routed requests Authors' Addresses Authors' Addresses Jouni Korhonen (editor) Broadcom Porkkalankatu 24 Helsinki FIN-00180 Finland Email: jouni.nospam@gmail.com Steve Donovan (editor) Oracle 7460 Warren Parkway Frisco, Texas 75034 United States Email: srdonovan@usdonovans.com Ben Campbell Oracle 7460 Warren Parkway Frisco, Texas 75034 United States Email: ben@nostrum.com Lionel Morand Orange Labs 38/40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France Phone: +33145296257 Email: lionel.morand@orange.com Korhonen, et al. Expires April 12, 2015 [Page 44] --------------060008090505020207050209-- From nobody Sat Oct 11 05:37:56 2014 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 8FFC11A1B83 for ; Sat, 11 Oct 2014 05:37:55 -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 w0GsdofcV54o for ; Sat, 11 Oct 2014 05:37:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 158491A1B91 for ; Sat, 11 Oct 2014 05:37:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141011123753.18837.86317.idtracker@ietfa.amsl.com> Date: Sat, 11 Oct 2014 05:37:53 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KkyFJGwBUYQeV8CaClL-EyevIM0 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: Sat, 11 Oct 2014 12:37:55 -0000 Changed milestone "Submit a document on 'Diameter Agent Overload' as a working group item", set state to active from review, accepting new milestone. Changed milestone "Submit a document on 'Diameter Overload Control Rate Abatement Algorithm' as a working group item", set state to active from review, accepting new milestone. Changed milestone "Submit I-D 'Diameter Agent Overload' to the IESG for consideration as a Proposed Standard ", set state to active from review, accepting new milestone. Changed milestone "Submit I-D 'Diameter Overload Control Rate Abatement Algorithm' to the IESG for consideration as a Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/dime/charter/ From nobody Mon Oct 13 05:06:52 2014 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 5BCE01A89B9 for ; Mon, 13 Oct 2014 05:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 U0pkFzvAOHRi for ; Mon, 13 Oct 2014 05:06:47 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C26D1A8987 for ; Mon, 13 Oct 2014 05:06:47 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-5b-543bc0543966 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 48.44.04081.450CB345; Mon, 13 Oct 2014 14:06:45 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.19]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Mon, 13 Oct 2014 14:06:44 +0200 From: Maria Cruz Bartolome To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Prep for next weeks DIME interim meeting Thread-Index: AQHP49iFm0T5ElHF2Ue0Cem2nzWE7pwt9CbA Date: Mon, 13 Oct 2014 12:06:43 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920984104C@ESESSMB101.ericsson.se> References: <5436A942.1010400@usdonovans.com> In-Reply-To: <5436A942.1010400@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvjW7oAesQg5PzWS3m9q5gs9jQxOPA 5LFkyU8mj1Vv+1gDmKK4bFJSczLLUov07RK4MhY2/GMruM9Wca6nnamBcSdrFyMnh4SAicTJ +d0sELaYxIV769lAbCGBo4wSm1dLdDFyAdmLGSX296xmBkmwCdhJXDr9ggnEFhHwlTjeeRqs WVjARmLR7OtQcVuJZd/a2CFsI4ldq7cBLePgYBFQlZi1jAckzAvUOmnNe3aIXboSe+Z3gO3l FNCT6Hk3G2wkI9A930+tARvJLCAucevJfCaIOwUkluw5zwxhi0q8fPwP6hclibWHt7NA1OtI LNj9iQ3C1pZYtvA1M8ReQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2hxanFSbrqRkV5q UWZycXF+nl5easkmRmCMHNzy22AH48vnjocYBTgYlXh4H/y0ChFiTSwrrsw9xCjNwaIkzrvw 3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzxiswPe+pe11ZyWMxO2vRDxo31yeFDouLS V/Rjve//21d346pYl9DDnJYU7kSFv6cnLdLM+Mpy4xn3QV/bdYsW/IsqMnvEvGXPnHJ+bT0R 2e9P1M1KOQv32vS5f837YpGgvfyLT/qT06u3uboset5ydpcy/x1N7f1zGfxyl315yLUlO8Bh mpgSS3FGoqEWc1FxIgA3q/xjcgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pqitNF_rDdcdW9ic8j_Z0EcELaA Subject: Re: [Dime] Prep for next weeks DIME interim meeting 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, 13 Oct 2014 12:06:49 -0000 Hello Steve, I would like to know if you have already considered all the comments I made= to version .03, and if not, what has been your proposal. If not considered= , I would need to go on then using version .03 A part from that, it would be very helpful if you could provide track chang= es on the doc or the diff file. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: jueves, 09 de octubre de 2014 17:27 To: dime@ietf.org Subject: [Dime] Prep for next weeks DIME interim meeting All, As we prepare for next weeks interim meeting, please remember to use the fo= llowing as the source document: https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-di= me-ovli-04.txt I've attached a copy for everyone's convenience. Regards, Steve From nobody Mon Oct 13 09:21:31 2014 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 7AAD11A1ACF for ; Mon, 13 Oct 2014 09:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 hVzi3r9rvVK6 for ; Mon, 13 Oct 2014 09:21:19 -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 0E4AB1A030B for ; Mon, 13 Oct 2014 09:21:19 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61116 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XdiN0-00035p-8D for dime@ietf.org; Mon, 13 Oct 2014 09:21:15 -0700 Message-ID: <543BFBF9.3060308@usdonovans.com> Date: Mon, 13 Oct 2014 11:21:13 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/alternative; boundary="------------070109000605050408040401" 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GCCUsC951MOXzOodeI7il1mNBn4 Subject: [Dime] DOIC Review of issues 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, 13 Oct 2014 16:21:21 -0000 This is a multi-part message in MIME format. --------------070109000605050408040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, The following is the list of open issues as of Monday, October 13. I've included my proposal for what needs to be done to close each issue. Regards, Steve ----- #23 DOIC behavior for realm overload Consensus reached that realm overload reports apply to requests that are not routed based on server selection. Need to finalize wording on the definition on host report then update the definition of route report indicating it is all requests that are not covered by the host report. Also need to review and update the loss report section to make sure that the behavior definition for both host and realm reports is complete and accurate. #25 Section 3.1.5 Diameter Agent Behavior Need definition of new error response. Need to determine if this is defined in DOIC or as an extension to RFC6733. Proposal is the later. This issue depends on #23, as #23 will result in the definition of behavior of reacting nodes for host and realm reports. The definitions hopefully will not be different for agents and Diameter endpoints. Need to make sure that use cases outlined in the agent scenario draft are addressed. #27 Behavior of agent acting on behalf of Client that does not support DOIC Depends on the resolution to the new error code issue. Probably need to define behavior for when the client support the new error code and for when it does not. #43 Overstated guidance on session-ending requests. Minor issue - requires proposed wording to close. #57 Handling of "Realm-Routed" Overload report type This is a dup of #23 and should be closed as such. #58 Multiple Reporting Nodes for realm-routed-request type reports Two proposals have been made: 1) Reporting nodes for realm reports must be kept in sync at all times with no additional behavior to handle the condition where they do get out of sync. 2) Reacting node only listens to the first node to report a new overload condition. This addresses case where reporting nodes get out of sync. Need to determine which approach to take. #60 Agent Overload Report Handling considerations This is a dup of #25. #61 Agent Capability Announcement Considerations This is a dup of #25. #66 Non-Supporting Agent Changing Origin-Host Two primary proposals: 1) Make it an operator configuration and test issue with no additional DOIC behavior defined. 2) Add an AVP to the OLR indicating the node that generated the report. The reacting node then detects that topology hiding behavior exists in the path taken by the request and can act accordingly. Need to determine approach to take. #67 OCS for Reporting Nodes - Expiry Time No consensus on whether or not this is an issue. One proposal is to make it clear that the OCS information discussed in the draft is an example and that reporting nodes can store different information as long as the DOIC signaling sent by the reporting node conforms with the DOIC specification. Requires further discussion. #68 Loss as the common abatemen algorithm Consensus reached to change the wording to the following: " Since the "loss" abatement algorithm [crossref] is mandatory to implement, DOIC can always be enabled between these two endpoints." #69 Report Type - Realm, with absent Destination-Host Multiple proposals for wording. This deals with the need to make sure that we update the definitions of host-report and realm-report. #70 Appendix B - Example Multiple issues have been discussed in this thread. I think there was consensus to say that a agent MAY change the OLR in the case where the server selects the rate algorithm, the agents supports rate and loss and the client only supports rate. Requires further discussion to determine what detailed changes are proposed. #71 Active overload report even if OC-OLR is not received Little discussion. Apparent consensus reached on proposed wording. #72 Reporting Node Behaviour when OC-OLR is not received Current document says an OLR must be included in every response. There is no agreement that this should be changed. #73 Clarifications On Mbit No list discussion on proposed changes. #74 Move section 3.7. Considerations for Applications Integrating the DOIC Solution to Appendix No list discussion on proposed change. --------------070109000605050408040401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

The following is the list of open issues as of Monday, October 13.  I've included my proposal for what needs to be done to close each issue.

Regards,

Steve

-----

#23     DOIC behavior for realm overload

Consensus reached that realm overload reports apply to requests that are not routed based on server selection. 

Need to finalize wording on the definition on host report then update the definition of route report indicating it is all requests that are not covered by the host report. 

Also need to review and update the loss report section to make sure that the behavior definition for both host and realm reports is complete and accurate.

#25     Section 3.1.5 Diameter Agent Behavior

Need definition of new error response.  Need to determine if this is defined in DOIC or as an extension to RFC6733.  Proposal is the later.

This issue depends on #23, as #23 will result in the definition of behavior of reacting nodes for host and realm reports.  The definitions hopefully will not be different for agents and Diameter endpoints.

Need to make sure that use cases outlined in the agent scenario draft are addressed.

#27     Behavior of agent acting on behalf of Client that does not support DOIC

Depends on the resolution to the new error code issue.  Probably need to define behavior for when the client support the new error code and for when it does not.

#43     Overstated guidance on session-ending requests.

Minor issue - requires proposed wording to close.

#57     Handling of "Realm-Routed" Overload report type

This is a dup of #23 and should be closed as such.

#58     Multiple Reporting Nodes for realm-routed-request type reports

Two proposals have been made:

1) Reporting nodes for realm reports must be kept in sync at all times with no additional behavior to handle the condition where they do get out of sync.

2) Reacting node only listens to the first node to report a new overload condition.  This addresses case where reporting nodes get out of sync.

Need to determine which approach to take.

#60     Agent Overload Report Handling considerations

This is a dup of #25.

#61     Agent Capability Announcement Considerations

This is a dup of #25.

#66     Non-Supporting Agent Changing Origin-Host

Two primary proposals:

1) Make it an operator configuration and test issue with no additional DOIC behavior defined.

2) Add an AVP to the OLR indicating the node that generated the report.  The reacting node then detects that topology hiding behavior exists in the path taken by the request and can act accordingly.

Need to determine approach to take.

#67     OCS for Reporting Nodes - Expiry Time

No consensus on whether or not this is an issue.  One proposal is to make it clear that the OCS information discussed in the draft is an example and that reporting nodes can store different information as long as the DOIC signaling sent by the reporting node conforms with the DOIC specification.

Requires further discussion.

#68     Loss as the common abatemen algorithm

Consensus reached to change the wording to the following:
" Since the "loss" abatement algorithm [crossref] is mandatory to implement, DOIC can always be enabled between these two endpoints."

#69     Report Type - Realm, with absent Destination-Host

Multiple proposals for wording.  This deals with the need to make sure that we update the definitions of host-report and realm-report.

#70     Appendix B - Example

Multiple issues have been discussed in this thread.  I think there was consensus to say that a agent MAY change the OLR in the case where the server selects the rate algorithm, the agents supports rate and loss and the client only supports rate.

Requires further discussion to determine what detailed changes are proposed.

#71     Active overload report even if OC-OLR is not received

Little discussion.  Apparent consensus reached on proposed wording.

#72     Reporting Node Behaviour when OC-OLR is not received

Current document says an OLR must be included in every response.  There is no agreement that this should be changed.

#73     Clarifications On Mbit

No list discussion on proposed changes.

#74     Move section 3.7. Considerations for Applications Integrating the DOIC Solution to Appendix

No list discussion on proposed change.
--------------070109000605050408040401-- From nobody Mon Oct 13 13:46:35 2014 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 79E8F1A004B for ; Mon, 13 Oct 2014 13:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 bpy1rnXc8Ghx for ; Mon, 13 Oct 2014 13:46:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 E5BE11A000A for ; Mon, 13 Oct 2014 13:46:29 -0700 (PDT) Received: from localhost ([::1]:57795 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XdmVd-0004Ju-ON; Mon, 13 Oct 2014 13:46:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 13 Oct 2014 20:46:25 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/dime/trac/ticket/75 Message-ID: <066.165d20d0969f53f2e18f5a88f737e2d5@trac.tools.ietf.org> X-Trac-Ticket-ID: 75 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Nrg1xVox8Qmxm6bM1ZZioL2P38M Cc: dime@ietf.org Subject: [Dime] [dime] #75 (draft-ietf-dime-ovli): Proposed changes to Terminology section X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:46:33 -0000 #75: Proposed changes to Terminology section Propose to add a few and change a few definitions in the terminology section. Proposed text (current text follows): Abatement Reaction to receipt of an overload report resulting in a reduction in traffic sent to the reporting node. Abatement actions include diversion and throttling. Abatement Algorithm An algorithm requested by reporting nodes and used by reacting nodes to reduce the amount of traffic sent during an occurrence of overload control. Diversion Abatement of traffic sent to a reporting node by a reacting node in response to receipt of an overload report. The abatement is achieved by diverting traffic from the reporting node to another Diameter node that is able to process the request. Throttling Throttling is the reduction of the number of requests sent to an entity. Throttling can include a client dropping requests, or an agent rejecting requests with appropriate error responses. In extreme cases servers can also throttle requests when requested reductions in traffic does not sufficiently address the overload scenario. Reporting Node A Diameter node that generates an overload report. (This may or may not be the overloaded node.) Reacting Node A Diameter node that acts upon an overload report. Overload Control State (OCS) State describing an occurrence of overload control maintained by reporting and reacting nodes. Overload Report (OLR) A set of AVPs sent by a reporting node indicating the start or continuation of an occurrence of overload control. Current text: Abatement Algorithm An algorithm requested by reporting nodes and used by reacting nodes to reduce the amount of traffic sent during an occurrence of overload control. Throttling Throttling is the reduction of the number of requests sent to an entity. Throttling can include a client dropping requests, or an agent rejecting requests with appropriate error responses. Clients and agents can also choose to redirect throttled requests to some other entity or entities capable of handling them. Editor's note: Propose to add a definition of Abatement to include both throttling and diversion (redirecting of messages) actions. Then to modify this definition to include just the rejecting of requests and adding a definition of diversion. Reporting Node A Diameter node that generates an overload report. (This may or may not be the overloaded node.) Reacting Node A Diameter node that consumes and acts upon a report. Note that "act upon" does not necessarily mean the reacting node applies an abatement algorithm; it might decide to delegate that downstream, in which case it also becomes a "reporting node". Overload Control State (OCS) State describing an occurrence of overload control maintained by reporting and reacting nodes. Overload Report (OLR) A set of AVPs sent by a reporting node indicating the start or continuation of an occurrence of overload control. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 13 13:50:59 2014 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 4A4D71A000A for ; Mon, 13 Oct 2014 13:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 Q5_YNzwZTh30 for ; Mon, 13 Oct 2014 13:50:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 174441A0023 for ; Mon, 13 Oct 2014 13:50:58 -0700 (PDT) Received: from localhost ([::1]:58010 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XdmZz-00061v-Ar; Mon, 13 Oct 2014 13:50:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 13 Oct 2014 20:50:55 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/76 Message-ID: <066.4f1da7960fc11058290d816d3513056d@trac.tools.ietf.org> X-Trac-Ticket-ID: 76 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/VwdmlB_6g1HZUYaoNg2A2b8bpp4 Cc: dime@ietf.org Subject: [Dime] [dime] #76 (draft-ietf-dime-ovli): Add report type ot OCS at reporting node X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:50:59 -0000 #76: Add report type ot OCS at reporting node Propose to add report type as part of the information included in the OCS of a reporting node. The results in adding Report Type to the list of information included in the OCS in section 4.2.1.2. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 13 13:54:14 2014 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 594AA1A006D for ; Mon, 13 Oct 2014 13:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 oqXJVz7Seaqg for ; Mon, 13 Oct 2014 13:54:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 D9A2B1A005F for ; Mon, 13 Oct 2014 13:54:10 -0700 (PDT) Received: from localhost ([::1]:58090 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xdmd5-0007Yt-V1; Mon, 13 Oct 2014 13:54:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 13 Oct 2014 20:54:07 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/77 Message-ID: <066.d4c405dbb2245ca94afc738db13a2a20@trac.tools.ietf.org> X-Trac-Ticket-ID: 77 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OdvynyYz8b4zPJeelUk0tsZnbdo Cc: dime@ietf.org Subject: [Dime] [dime] #77 (draft-ietf-dime-ovli): Section 4.2.3 - Reporting node behavior (overload report handling) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:54:12 -0000 #77: Section 4.2.3 - Reporting node behavior (overload report handling) Propose adding the following two paragraphs after the third paragraph (location isn't critically important): The reporting node MUST include the OC-Validity-Duration AVP in the OLR. The reporting node MUST include a report-type in the OLR. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 13 13:55:24 2014 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 A0F291A0072 for ; Mon, 13 Oct 2014 13:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 WOXrEHVcGnZi for ; Mon, 13 Oct 2014 13:55:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 661AC1A0055 for ; Mon, 13 Oct 2014 13:55:20 -0700 (PDT) Received: from localhost ([::1]:58155 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XdmeD-0007xY-Qa; Mon, 13 Oct 2014 13:55:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 13 Oct 2014 20:55:17 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/78 Message-ID: <066.7563cf099a48a0e6ca19394c0b608cbd@trac.tools.ietf.org> X-Trac-Ticket-ID: 78 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6KniqOu6DQjyZGd-Qp-qAge-rBk Cc: dime@ietf.org Subject: [Dime] [dime] #78 (draft-ietf-dime-ovli): Remove section 5.2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:55:21 -0000 #78: Remove section 5.2 Propose to remove section 5.2 as it is redundant. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 13 13:59:03 2014 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 2A4B71A0029 for ; Mon, 13 Oct 2014 13:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 jNhm9DN0mcXg for ; Mon, 13 Oct 2014 13:59:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 00BA31A001B for ; Mon, 13 Oct 2014 13:59:00 -0700 (PDT) Received: from localhost ([::1]:58309 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xdmhm-0000EJ-4q; Mon, 13 Oct 2014 13:58:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 13 Oct 2014 20:58:58 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/79 Message-ID: <066.baf6a379d5a23d4c1fc75604089389cd@trac.tools.ietf.org> X-Trac-Ticket-ID: 79 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/TbfdnwojyneQRun59ynyjIbq6Bo Cc: dime@ietf.org Subject: [Dime] [dime] #79 (draft-ietf-dime-ovli): Section 5.4 - remove editor's note X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:59:02 -0000 #79: Section 5.4 - remove editor's note Propose to remove the following editor's note from section 5.4 as the suggested guidance already exists. Editor's note: Need to add additional guidance to slowly increase the rate of traffic sent to avoid a sudden spike in traffic, as the spike in traffic could result in oscillation of the need for overload control. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 13 14:00:28 2014 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 F23251A008C for ; Mon, 13 Oct 2014 14:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 KAYQ_9DYGxmt for ; Mon, 13 Oct 2014 14:00:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 D8FB21A008D for ; Mon, 13 Oct 2014 14:00:23 -0700 (PDT) Received: from localhost ([::1]:58371 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xdmj6-0000d5-Dm; Mon, 13 Oct 2014 14:00:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 13 Oct 2014 21:00:20 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/80 Message-ID: <066.5539af770d4d4b42fb59894a29e8524f@trac.tools.ietf.org> X-Trac-Ticket-ID: 80 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7DN2opmW01Na79vgq0P5hROykLg Cc: dime@ietf.org Subject: [Dime] [dime] #80 (draft-ietf-dime-ovli): 6.1. OC-Supported-Features AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 21:00:27 -0000 #80: 6.1. OC-Supported-Features AVP Propose removing the following from the last paragraph. Also propose removing the editor's note: If there is no single matching capability the reacting node MUST act as if it does not implement DOIC and cease inserting any DOIC related AVPs into any Diameter messages with this specific reacting node. Editor's note: The last sentence conflicts with the last sentence two paragraphs up. In reality, there will always be at least one matching capability as all nodes supporting DOIC must support the loss algorithm. Suggest removing the last sentence. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 13 14:04:51 2014 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 627D01A0024 for ; Mon, 13 Oct 2014 14:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 AOrRutwwWsn8 for ; Mon, 13 Oct 2014 14:04:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 028B91A0029 for ; Mon, 13 Oct 2014 14:04:49 -0700 (PDT) Received: from localhost ([::1]:58558 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XdmnO-0001V5-BE; Mon, 13 Oct 2014 14:04:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 13 Oct 2014 21:04:46 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/81 Message-ID: <066.50e52056ddaf429706618e24a3ab2a3e@trac.tools.ietf.org> X-Trac-Ticket-ID: 81 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/wS5vZvBxNBrs-P4paW9BHvnChDA Cc: dime@ietf.org Subject: [Dime] [dime] #81 (draft-ietf-dime-ovli): 6.3. OC-OLR AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 21:04:50 -0000 #81: 6.3. OC-OLR AVP Propose adding the following to the third paragraph: Before: Note that if a Diameter command were to contain multiple OC-OLR AVPs they all MUST have different OC-Report-Type AVP value. After: Note that if a Diameter command were to contain multiple OC-OLR AVPs they all MUST have different OC-Report-Type AVP value. It is recommended that the reacting node process the first OLR and silently discard other OLRs of the same type. Also propose removing the following editor's note: Editor's note: Need to specify what happens when two reports of the same type are received. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 13 14:07:06 2014 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 AA0D81A001B for ; Mon, 13 Oct 2014 14:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 N4KzllThG7kv for ; Mon, 13 Oct 2014 14:07:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 EFB9B1A0019 for ; Mon, 13 Oct 2014 14:06:59 -0700 (PDT) Received: from localhost ([::1]:58657 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XdmpV-0001yg-EY; Mon, 13 Oct 2014 14:06:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 13 Oct 2014 21:06:57 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/82 Message-ID: <066.d3ed74d24b21e564d1e8254e3d1cbd6d@trac.tools.ietf.org> X-Trac-Ticket-ID: 82 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BPK6f_BqInbl_RY11v8YyLRqHx4 Cc: dime@ietf.org Subject: [Dime] [dime] #82 (draft-ietf-dime-ovli): 6.4. OC-Sequence-Number AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 21:07:01 -0000 #82: 6.4. OC-Sequence-Number AVP Propose modifying the second paragraph: Before: From the functionality point of view, the OC-Sequence-Number AVP MUST be used as a non-volatile increasing counter between two DOIC nodes. After: From the functionality point of view, the OC-Sequence-Number AVP MUST be used as a non-volatile increasing counter for an individual overload report between two DOIC nodes. Also propose adding the following paragraph at the end of the section: The sequence number is not required to be greater between discrete overload reports. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 13 14:08:06 2014 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 711041A001B for ; Mon, 13 Oct 2014 14:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 c4ldCdSsy6eV for ; Mon, 13 Oct 2014 14:07:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 C43C41A0024 for ; Mon, 13 Oct 2014 14:07:59 -0700 (PDT) Received: from localhost ([::1]:58678 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XdmqU-000248-GX; Mon, 13 Oct 2014 14:07:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 13 Oct 2014 21:07:58 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/83 Message-ID: <066.97e9aa79dd56fc024effa9ff255e2f28@trac.tools.ietf.org> X-Trac-Ticket-ID: 83 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XuDmEf7RcI3WvZPRhr9pPS4Js2M Cc: dime@ietf.org Subject: [Dime] [dime] #83 (draft-docdt-dime-ovli): 6.6. OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 21:08:04 -0000 #83: 6.6. OC-Report-Type AVP Propose removing the editor's note. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-docdt-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 13 14:10:26 2014 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 82EB01A0029 for ; Mon, 13 Oct 2014 14:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 7iFKDl3B8i2u for ; Mon, 13 Oct 2014 14:10:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 801D61A0024 for ; Mon, 13 Oct 2014 14:10:17 -0700 (PDT) Received: from localhost ([::1]:58760 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xdmsg-0002TT-L0; Mon, 13 Oct 2014 14:10:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 13 Oct 2014 21:10:14 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/84 Message-ID: <066.28524b7f3851b1ca821a52ca53aabef6@trac.tools.ietf.org> X-Trac-Ticket-ID: 84 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2v8JAVGho-xHmZCg1ShJsCeMzxk Cc: dime@ietf.org Subject: [Dime] [dime] #84 (draft-ietf-dime-ovli): 6.6. OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 21:10:21 -0000 #84: 6.6. OC-Report-Type AVP Propose removing the following paragraph: The default value of the OC-Report-Type AVP is 0 (i.e. the host report). -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 13 16:04:25 2014 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 B80D41A1A3A for ; Mon, 13 Oct 2014 16:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, 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 G1z0r29E6Yds for ; Mon, 13 Oct 2014 16:04:21 -0700 (PDT) Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) (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 7F3D51A1A34 for ; Mon, 13 Oct 2014 16:04:21 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9DN4J3O044635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Oct 2014 18:04:20 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <066.50e52056ddaf429706618e24a3ab2a3e@trac.tools.ietf.org> Date: Mon, 13 Oct 2014 18:04:18 -0500 X-Mao-Original-Outgoing-Id: 434934258.906684-aa4c1ece026dcf9f6bcb9ea320e75738 Content-Transfer-Encoding: quoted-printable Message-Id: <657165D5-B716-4E30-98AB-92BDCD347EC7@nostrum.com> References: <066.50e52056ddaf429706618e24a3ab2a3e@trac.tools.ietf.org> To: dime@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ARFeZpd7nK0ylDsFyiL0_hYxvNg Subject: Re: [Dime] [dime] #81 (draft-ietf-dime-ovli): 6.3. OC-OLR 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: Mon, 13 Oct 2014 23:04:24 -0000 On reflection, I don't agree on this one. I don't think we need to = specify how a recipient handles a violation of a MUST level requirement. = (Why would that be different for this and any other MUST?) Is there a way you could get multiple reports of the same type in a = message without something violating the MUST? On Oct 13, 2014, at 4:04 PM, dime issue tracker = wrote: > #81: 6.3. OC-OLR AVP >=20 > Propose adding the following to the third paragraph: >=20 > Before: >=20 > Note that if a Diameter command were to contain multiple OC-OLR = AVPs > they all MUST have different OC-Report-Type AVP value. >=20 > After: >=20 > Note that if a Diameter command were to contain multiple OC-OLR = AVPs > they all MUST have different OC-Report-Type AVP value. It is > recommended that the reacting node process the first OLR and silently > discard other OLRs of the same type. >=20 > Also propose removing the following editor's note: >=20 > Editor's note: Need to specify what happens when two reports of > the same type are received. >=20 > --=20 > = -------------------------------------+------------------------------------= - > Reporter: | Owner: draft-ietf-dime- > srdonovan@usdonovans.com | ovli@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-ietf-dime-ovli | Version: > Severity: Active WG Document | Keywords: > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: > dime >=20 From nobody Mon Oct 13 16:15:41 2014 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 B3DEE1A1A59 for ; Mon, 13 Oct 2014 16:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, 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 6vcK1pHOysVr for ; Mon, 13 Oct 2014 16:15:15 -0700 (PDT) Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) (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 2CC661A1A45 for ; Mon, 13 Oct 2014 16:15:14 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9DNFC1p045604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Oct 2014 18:15:13 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <066.d4c405dbb2245ca94afc738db13a2a20@trac.tools.ietf.org> Date: Mon, 13 Oct 2014 18:15:11 -0500 X-Mao-Original-Outgoing-Id: 434934911.633419-b811d5ecd14b9525719224cbc4f02f5c Content-Transfer-Encoding: quoted-printable Message-Id: References: <066.d4c405dbb2245ca94afc738db13a2a20@trac.tools.ietf.org> To: dime@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SRlLhFJDaixIOzqyVJmD-0DSpLM Subject: Re: [Dime] [dime] #77 (draft-ietf-dime-ovli): Section 4.2.3 - Reporting node behavior (overload report handling) 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, 13 Oct 2014 23:15:18 -0000 Are these not mandatory in the in the AVP definition? If they aren't = they should be, and if they are, the text is redundant. On Oct 13, 2014, at 3:54 PM, dime issue tracker = wrote: > #77: Section 4.2.3 - Reporting node behavior (overload report = handling) >=20 > Propose adding the following two paragraphs after the third paragraph > (location isn't critically important): >=20 > The reporting node MUST include the OC-Validity-Duration AVP in the > OLR. >=20 > The reporting node MUST include a report-type in the OLR. >=20 > --=20 > = -------------------------------------+------------------------------------= - > Reporter: | Owner: draft-ietf-dime- > srdonovan@usdonovans.com | ovli@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-ietf-dime-ovli | Version: > Severity: Active WG Document | Keywords: > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: > dime >=20 From nobody Tue Oct 14 09:07:44 2014 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 1EA4C1A8996 for ; Tue, 14 Oct 2014 09:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 jWXB-9tESBsZ for ; Tue, 14 Oct 2014 09:07:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 AF2B11A88F2 for ; Tue, 14 Oct 2014 09:07:40 -0700 (PDT) Received: from localhost ([::1]:34222 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xe4dK-0000Qx-N9; Tue, 14 Oct 2014 09:07:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Tue, 14 Oct 2014 16:07:34 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/85 Message-ID: <066.8ce734c1c66c770a886774c6bf72f7be@trac.tools.ietf.org> X-Trac-Ticket-ID: 85 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/rPE8SWIhsDOWI3eBqq78pNrcZo0 Cc: dime@ietf.org Subject: [Dime] [dime] #85 (draft-ietf-dime-ovli): New error response X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:07:42 -0000 #85: New error response This issue is implied by others but is being added to make sure that the need for a new error response code (or modification of an existing error response code) to address requests that are rejected due to overload abatement. The required behavior in response to the new code is to not retry the transaction. This response code will likely be defined in a separate document and referred to by the DOIC specification. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Oct 15 03:29:18 2014 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 CB36B1A1A97 for ; Wed, 15 Oct 2014 03:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 XECeGrM1GBbw for ; Wed, 15 Oct 2014 03:29:15 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6B21A000B for ; Wed, 15 Oct 2014 03:29:14 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-27-543e4c78437f Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D0.72.24955.87C4E345; Wed, 15 Oct 2014 12:29:13 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.19]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Wed, 15 Oct 2014 12:29:12 +0200 From: Birgit Falter To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #83 (draft-docdt-dime-ovli): 6.6. OC-Report-Type AVP Thread-Index: AQHP5ynNUSQiLX1rOU22FXqxT/IbgJww91dA Date: Wed, 15 Oct 2014 10:29:12 +0000 Message-ID: References: <066.97e9aa79dd56fc024effa9ff255e2f28@trac.tools.ietf.org> In-Reply-To: <066.97e9aa79dd56fc024effa9ff255e2f28@trac.tools.ietf.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_E8E916316CD53248AECB69A86737C4E40988E193ESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjW6lj12IwexDnBZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoEr48frTywFV5QrZi0/ydTAeEW+i5GTQ0LARGLfyWZmCFtM4sK9 9WxdjFwcQgJHGSXW3l7DBOEsZpQ4O6GftYuRg4NNwECi5Wc5iCkioCxx+pcDiCksEChx8lAM RDRIovdPPchEEQEjiZO7HzKC2CwCqhKNa4+xgNi8Ar4SjRN3M4HYQgJuErda34DZnALuEo2t C1hBbEYBWYkNG86DXcYsIC5x68l8JogrBSSW7DkPdbGoxMvH/8DukhBQkpi2NQ2iPF9iXsNv NohVghInZz5hmcAoMgvJpFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGEWL U4uTctONjPVSizKTi4vz8/TyUks2MQJj5+CW36o7GC+/cTzEKMDBqMTDq3DVNkSINbGsuDL3 EKM0B4uSOO/Cc/OChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAGMeswCAacOqWznfc3i9zS 8kXfNq773llyUzPwj3gtj01n3ATZ8tmKjnN0ey8fcbKyWD71g6DS376MbcEq6d+OyHccPMHx 7cHhRmNL3z+smxLq1cUObr/Aa2AR4s19/pXo8hkr+g9PO6RfXmFx0Mm045lP9DLBifcaZGfw zqu8y/3DL3PVRW4lluKMREMt5qLiRAA3Xz9/fgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/O3KV-LxWbvv0D94IggpSK0QZvss Subject: Re: [Dime] [dime] #83 (draft-docdt-dime-ovli): 6.6. OC-Report-Type 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: Wed, 15 Oct 2014 10:29:17 -0000 --_000_E8E916316CD53248AECB69A86737C4E40988E193ESESSMB101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Maria, OK. /irgit -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker Sent: Monday, October 13, 2014 11:08 PM To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #83 (draft-docdt-dime-ovli): 6.6. OC-Report-Type AVP #83: 6.6. OC-Report-Type AVP Propose removing the editor's note. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-docdt-dime- srdonovan@usdonovans.com | ov= li@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E8E916316CD53248AECB69A86737C4E40988E193ESESSMB101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Maria,
 
OK.
/irgit
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ie= tf.org] On Behalf Of dime issue tracker
Sent: Monday, October 13, 2014 11:08 PM
To: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
Cc: dime@ietf.org
Subject: [Dime] [dime] #83 (draft-docdt-dime-ovli): 6.6. OC-Report-Type AVP=
 
#83: 6.6.  OC-Report-Type AVP
 
Propose removing the editor's note.
 
--
-------------------------------------+----------------------------= ---------
Reporter:          =             &nb= sp;    |      Owner:  draft-do= cdt-dime-
  srdonovan@usdonovan= s.com           |&nbs= p; ovli@tools.ietf.org
     Type:  defect    &nb= sp;            =   |     Status:  new
Priority:  major        =             |  = Milestone:
Component:  draft-docdt-dime-ovli    |  =   Version:
Severity:  Active WG Document      = ; |   Keywords:
-------------------------------------+----------------------------= ---------
 
 
_______________________________________________
DiME mailing list
 
 --_000_E8E916316CD53248AECB69A86737C4E40988E193ESESSMB101erics_-- From nobody Wed Oct 15 05:33:32 2014 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 1788D1A6F13 for ; Wed, 15 Oct 2014 05:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 QcznqknBwPDi for ; Wed, 15 Oct 2014 05:33:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574B11A6F12 for ; Wed, 15 Oct 2014 05:33:28 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 4962D2AC467 for ; Wed, 15 Oct 2014 14:33:26 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 2A4E315804E for ; Wed, 15 Oct 2014 14:33:26 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 14:33:25 +0200 From: To: MORAND Lionel IMT/OLN , "dime@ietf.org" Thread-Topic: DIME WG Interim Meeting Thread-Index: Ac/LQpFuDUgBmi8IRWaBzz3UFKCQogdMXKZw Date: Wed, 15 Oct 2014 12:33:25 +0000 Message-ID: <22560_1413376406_543E6996_22560_2047_1_6B7134B31289DC4FAF731D844122B36E7CFEFB@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <11294_1410166542_540D6F0E_11294_720_1_6B7134B31289DC4FAF731D844122B36E6FF6E6@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <11294_1410166542_540D6F0E_11294_720_1_6B7134B31289DC4FAF731D844122B36E6FF6E6@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.24.114819 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pmTi9MXspqrHQbGLhjh9QEKUCmk Subject: Re: [Dime] DIME WG Interim Meeting 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, 15 Oct 2014 12:33:31 -0000 Hi, Here is the agenda for the next interim meeting: THURSDAY, October 16, 2014 0930-1230 Morning Session I Meeting Room: S905 ROYA * Meeting Preliminaries - Note Well - Note takers - Agenda bashing * Status of the draft since IETF90 - Changes in v04 - Closed Issues - Pending open issues - New open Issues THURSDAY, October 16, 2014 1400-1800 Afternoon Session I Meeting Room: S905 ROYA * Review of the proposed solutions and Discussion on new/pending open issue= s (1/2) FRIDAY, October 17, 2014 0930-1230 Morning Session II Meeting Room: S905 ROYA * Review of the proposed solutions and Discussion on new/pending open issue= s (2/2) * Conclusions FRIDAY, October 17, 2014 1400-1700 Afternoon Session II Meeting Room: S905 ROYA * DOIC next steps and working procedure till WGLC/IETF91 * Wrap-up & Conclusion * End of the meeting ***************************************************** De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran= ge.com Envoy=E9=A0: lundi 8 septembre 2014 10:56 =C0=A0: iesg-secretary@ietf.org; dime@ietf.org Objet=A0: [Dime] DIME WG Interim Meeting The IETF DIME WG will hold an Interim Meeting on October 16-17, 2014. The meeting will take place at: Orange Labs Sophia-Antipolis (close to ETSI premises) 905 Rue Albert Einstein=20 06560 VALBONNE, FRANCE Meeting Room: S905 ROYA. The agenda of the meeting is to work on the remaining open issues on the Di= ameter Overload Control indication Conveyance (DOIC) draft, in order to pro= duce a final version for IETF Last-Call before the end of the year. A detai= led agenda will be provided later on the DIME mailing list. If you'd like to attend, please register by sending an email to the DIME WG= chairs (dime-chairs@tools.ietf.org).=20 Here is a preliminary list of participants: - Jouni Korhonen - Lionel Morand - Steve Donovan - Ben Campbell - Maria Cruz Bartolome - Jean-Jacques Trottin - Susan Shishufeng - Ulrich Wiehe Regards, Lionel & Jouni ___________________________________________________________________________= ______________________________________________ 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. From nobody Wed Oct 15 06:41:57 2014 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 955F51A6FB7 for ; Wed, 15 Oct 2014 06:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tdpbve6yjOL for ; Wed, 15 Oct 2014 06:41:54 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1DCA1A1ADE for ; Wed, 15 Oct 2014 06:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=318; q=dns/txt; s=iport; t=1413380512; x=1414590112; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=BcwU2Lx1TeBfPayLco0OhM9x93I0Pbd3Jy+Gdbt06X8=; b=W8Ob6OfgCu3tfjH5Lbh37ckt/AepzT+Fn5RLWmdMGqUbpDKvkTtg/LUc UEa4foIrmibSyPj4fHBZb5n8giWAuo3wyuWqNYNEKNZQIaBIevhnY4Ba1 W1zAh4Mw+8GILwV+4soP6z4k3ueU4hIPMNXdYz9XYwt2bNhNpv6OoCksY Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAMB4PlStJssW/2dsb2JhbABb2AmBKgF9hEFAATwWGAMCAQIBWAEHAQGIOsgxAQEBBwIgj2EcAQFPHYQ1AQSdVIEwg0aCcocahxiDeTuBPoE7AQEB X-IronPort-AV: E=Sophos;i="5.04,724,1406592000"; d="scan'208";a="207590220" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 15 Oct 2014 13:41:50 +0000 Received: from [10.61.194.75] ([10.61.194.75]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9FDfnb7024939; Wed, 15 Oct 2014 13:41:49 GMT Message-ID: <543E799D.9050809@cisco.com> Date: Wed, 15 Oct 2014 15:41:49 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: draft-ietf-dime-e2e-sec-req@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/CFwF3ezfn60_7dCrcoJmCsLobLk Cc: dime mailing list Subject: [Dime] Mail regarding draft-ietf-dime-e2e-sec-req 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, 15 Oct 2014 13:41:55 -0000 Dear authors, Can you please progress draft-ietf-dime-e2e-sec-req. Two data points: - last update was October 21, 2013 - WG milestone: Dec 2012, Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC Regards, Benoit From nobody Wed Oct 15 13:36:50 2014 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 38B981ACCEE for ; Wed, 15 Oct 2014 13:36:49 -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 xNCuHaSpuQvJ for ; Wed, 15 Oct 2014 13:36:47 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6094B1ACD60 for ; Wed, 15 Oct 2014 13:36:21 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gm9so1780190lab.13 for ; Wed, 15 Oct 2014 13:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=engA1MKC5AWOk+rdEhUudH3kgssZYIfzaJLEvBK3yOo=; b=usiILs3SSjtIdvoXrOHcCvryAEX1lhzwDnAr1/l/SaQHtmAc3Ax/Al3r5OYUZqIK6A 9B56dF7miF7ieNQ/exP8WLMwV1HmRG7QUklzMetpawpPY++Wk+VxYXohsQKgozyBayEB IAiRHe9AQijIX9XSnRKpC1cUmSxmvFUzZTTUpjNJ4we6hzoqdybzaLU7/BitmDT+b1uK K7KR0J1knGdEdvTwpSaokV1OentH2H/BMwdDQaITGiyN8YixNWiHvZHgR0dinrvyzF/p 3mqbRLlcfFqCqSOPWk/moWanrPViSbLE/wdycb8E3Qhz5Sshlr70nXwqkBqumqisTJET afSA== X-Received: by 10.112.189.10 with SMTP id ge10mr14744415lbc.23.1413405379579; Wed, 15 Oct 2014 13:36:19 -0700 (PDT) Received: from [10.17.0.23] ([83.150.126.201]) by mx.google.com with ESMTPSA id lk5sm5484451lac.45.2014.10.15.13.36.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 13:36:18 -0700 (PDT) Message-ID: <543EDAC0.5070500@gmail.com> Date: Wed, 15 Oct 2014 23:36:16 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Donovan , dime@ietf.org References: <5436A942.1010400@usdonovans.com> <5436B9C5.7080007@usdonovans.com> In-Reply-To: <5436B9C5.7080007@usdonovans.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/oHsJ0KA3IdiMRwatzQbTFZmgg4s Subject: Re: [Dime] Prep for next weeks DIME interim meeting 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, 15 Oct 2014 20:36:49 -0000 Hi I had a quick read on the document. This is just mostly for editorials. There are still places where the same reacting and reporting node behavior is told again and again. This is generally error prone and maybe we should check how to possible avoid the repetition.. - Jouni --------------------------------------------- ** Section 1 and 3.2 o s/refered/referred ** Section 3 namely the "loss" algorithm Section 5). Future specifications may ^^^^^^ unknown AVPs through unmolested. The report types described in this ^^^^^^^^^^^^ o The wordind is a bit "funny". I would change to unchanged, for example. o s/fulfill/fulfil ** Section 3.3 o s/overlaod/overload o s/Validaty/Validity ** Section 3.4 o s/occurances/occurrences ** Section 3.6.2 o favorable? Should it be "favourable"? ** Section 4.1.2 o s/reqeust/request ** Section 4.1.3. Agent Behavior (Normative) Editor's note -- Need to add this section. ^^^^^^^^ o Maybe just add a forward note to future specs? ** Section 4.2.1.2 o agree with the editor's note. there is no way how the reporting node would know when the OLR has for sure time out in reacting node. Recommend removing the paragraph. ** Section 4.2.1.3 o The text starts using "app-id", "Orig-host" etc here. Use correct wording here like "application-id", "Origin-Host" etc. o "Reacting nodes delete an OCS when it expires (i.e. when current time minus reception time is greater than validity duration)." Reception time of what? A quick read here leads to time delta of 0. o Agree with the editor's note. Propose using the text in the editor's note as-is. o Regarding the OCS state, use the same language as in previous paragraphs. For example use "Algorithm" not "Alg" etc. o Agree with the editor's note on sending update with validity duration 0. ** Section 4.2.3. these DOIC nodes See Section 4.1 for further discussion on the ^^^^^ ** Section 4.2.4 o Add a note that this is for future specs? ** Section 4.3 The extention may also define new AVPs for use in DOIC Capability ^^^^^^ Anouncement and for use in DOIC Overload reporting. These new AVP ^^^^ existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED. ^^^^^^^^^^^^^^^^^^ o RFC2119 language issue. Use e.g. "..SHOULD NOT be used." ** Section 5.2 o I think this section can be removed. ** Section 5.4 o I think the editor's note is not needed and enough guidance is already given for implementers. The goal of this behavior is to reduce the probability of overload condition thrashing where an immediate transition from 100% reduction to 0% reduction results in the reporting node moving quickly back into an overload condition. o Use normal indentation.. ** Section 6 When added to existing commands, both OC-Feature-Vector and OC-OLR ^^^^^^^^ o Or rather applications? ** Section 6.1 o Agree with the editor's note and propose removeing the sentence. ** Section 6.3. o Regarding the editor's note I propose that the latter OC-OLR is disgarded and the event is logged. 10/9/2014 7:37 PM, Steve Donovan kirjoitti: > Here's a cleaner version of the .txt document. > > Steve > > On 10/9/14, 10:26 AM, Steve Donovan wrote: >> All, >> >> As we prepare for next weeks interim meeting, please remember to use >> the following as the source document: >> >> https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-04.txt >> >> >> I've attached a copy for everyone's convenience. >> >> Regards, >> >> Steve >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Oct 15 13:48:09 2014 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 12FC91ACD3F for ; Wed, 15 Oct 2014 13:48:06 -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, HTML_MESSAGE=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 2zgBBWjEO22y for ; Wed, 15 Oct 2014 13:48:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C04761ACD40 for ; Wed, 15 Oct 2014 13:47:54 -0700 (PDT) Received: from 84383542d82a.netpoint.com (187.31.0.109.rev.sfr.net [109.0.31.187]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9FKlcqx094694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2014 15:47:42 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 187.31.0.109.rev.sfr.net [109.0.31.187] claimed to be 84383542d82a.netpoint.com Content-Type: multipart/alternative; boundary="Apple-Mail=_0895D03F-0F00-44AE-98BA-8EA7C334FFD5" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520B965@DEMUMBX014.nsn-intra.net> Date: Wed, 15 Oct 2014 22:47:32 +0200 X-Mao-Original-Outgoing-Id: 435098852.701943-a6342bd6aa8a8557e57db0a9dc3ca02b Message-Id: <28EDD2E6-0E1E-4E8D-8FE8-9E5F0F6AA05E@nostrum.com> References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> <5409C5A4.5090203@usdonovans.com> <087A34937E64E74E848732CFF8354B920983BD00@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B920983BF65@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681520B965@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/UohUM8p5btESrA9hObOocvDqr94 Cc: "draft-ietf-dime-ovli@tools.ietf.org" , "dime@ietf.org" Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host 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, 15 Oct 2014 20:48:06 -0000 --Apple-Mail=_0895D03F-0F00-44AE-98BA-8EA7C334FFD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Ulrich, I think I agree with your intent, but I think the text has gotten more = complicated than it needs to be. Here's a proposed alternative: In 6.6: 0 A host report. The reacting node applies overload abatement to = the set of "host-routed" requests (see Section 3) that would otherwise be served by a node with a Diameter-Identity that matches the = Origin-Host AVP value of the Diameter answer message that contained the report. 1 A realm report. The reacting node applies overload abatement to = the set of "realm-routed" requests (see Section 3), where the Destination-Realm AVP value from the request matches the = Origin-Realm AVP value of the Diameter answer message that=20 contained the report. Then, replace the 2nd and 3rd to last paragraphs and the last line of = the 4th to last paragraph of Section 3 with the following: This document defines report types for overload of a specific server, = and for overload of an entire realm. A request is considered to be "host-routed" by a Diameter node if that = node has advance knowledge that the request will be served by a = particular destination. There are several ways a node can know this. For = example, the request could contain a Destination-Host AVP that matches = the destination. The sending node may perform final server selection.. = Or the sending node could be aware of some routing policy that will = force a request to go to the particular destination. (e.g., perhaps all = requests for a particular user go to a specific server). A request is considered to be "realm-routed" by a Diameter node if that = node does not know the actual destination for the request. For example, = the sending node may forward the request to an agent, based on the = routing table entry for the request's application and realm. The sending = node may have no idea where the agent might forward the request. The distinction of whether a given request is "host-routed" or = "realm-routed" is from the perspective of a particular node sending = node. For example, a request may be "realm-routed" from the perspective = of the client, but "host-routed" from the perspective of an agent that = performs the final server selection. In general, any "realm-routed" = request will eventually become a host-routed request as it traverses a = Diameter network. A report of type "host" is sent to request a reduction of offered load = for a specific server for the application-id indicated in the = transaction. When receiving an OLR of type "host", a reacting node = applies overload abatement to host routed requests that would otherwise = go to the overloaded server. The reacting node applies overload = abatement to the set of "host-routed" requests that the reacting node = knows will be served by the server that matches the Origin-Host AVP of = the message that contained report. A report type of "realm" is sent to indicate the overload of all servers = in a realm for the application-id. When receiving an OLR of type = "realm", a reacting node applies overload abatement to the set of = "realm-routed" requests destined for the realm indicate by the = Origin-Realm AVP of the message that contained the report. On Sep 26, 2014, at 12:37 PM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > Mcruz, JJ, >=20 > Maybe I missed your point, but my understanding is a bit different.=20 > Please see the attached proposal. >=20 > Best regards > Ulrich >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz = Bartolome > Sent: Friday, September 26, 2014 11:58 AM > To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; = draft-ietf-dime-ovli@tools.ietf.org > Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - = Realm, with absent Destination-Host >=20 > Dear JJ, all >=20 > I think I understand your concern. > I modified text in clause 6.6 to clarify this point. Attached. > Let me know your opinions. > Best regards > /MCruz >=20 >=20 > -----Original Message----- > From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) = [mailto:jean-jacques.trottin@alcatel-lucent.com]=20 > Sent: viernes, 26 de septiembre de 2014 10:12 > To: Maria Cruz Bartolome; dime@ietf.org; = draft-ietf-dime-ovli@tools.ietf.org > Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - = Realm, with absent Destination-Host >=20 >=20 > Hi Maria Cruz >=20 > 1) The hereafter proposed text is in a sub part of section 6.6 = addressing the overload treatment when the OC-report type indicates = realm report so according to a Realm type OLR. The proposed text = mentions "...Origin-Host AVP of the received message that contained the = OC-OLR AVP". This OC-OLR AVP can be understood as the Realm type OLR = subject of this section 6.6 subpart (this was my first reading), but it = is another report which is a host type OLR generated by this peer.=20 > As you said we have to distinguish when either a host or a realm = report to be applied, so here the proposal is to exclude from the text = the case where the reacting node has an active type Host type OLR of = which the Origin Host match the peer identity, as for this case the host = type OLR will be applied. On this basis I would propose write "Host type = OC-OLR AVP" as hereafter. =20 >=20 > "The Destination-Host AVP is absent in the request and the value of = peer identity associated with the connection used to send the request = does not match the value of the Origin-Host AVP of a received message = that contained a Host type OC-OLR AVP" >=20 > 2) When thinking a bit more to this case where the reacting node is = directly connected to the reporting node (eg a Client directly connected = to two or more servers, without intermediate DA, or a DA acting as a = reacting node directly connected to servers). The servers usually only = send Host type reports (I know there is a debate on servers sending = realm reports), so the reacting node will not receive Realm reports. = For requests for which there is no destination Host, the reacting node = will select the peer according to the host OLRs it has or not for each = of the peers (eg a peer that is not overload or with a small overload ) = and then apply the abatement/throttling according to the Host type OLR = of this peer. I think we have the same understanding. =20 >=20 >=20 > Best regards >=20 > JJacques=20 >=20 > -----Message d'origine----- > De : Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] > Envoy=E9 : jeudi 25 septembre 2014 18:28 > =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; = draft-ietf-dime-ovli@tools.ietf.org > Objet : RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - = Realm, with absent Destination-Host >=20 > Dear JJ, >=20 > I do not understand your point. >=20 > Proposed clarification has the purpose to allow a reacting node to = distinguish when either a host or a realm report shall apply. >=20 > Some time ago we based such a distinction on the presence (meaning = host report) or absence (meaning realm report). > Now we have covered the case for host reports when the host is absent = but it refers to the directly connected peer. Therefore, just absence = does not allow the reacting node to identify it has to apply a realm = report. >=20 > Let me know if this clarifies, or if I may be missing your point. > Thanks > /MCruz >=20 >=20 > -----Original Message----- > From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) = [mailto:jean-jacques.trottin@alcatel-lucent.com] > Sent: viernes, 12 de septiembre de 2014 14:13 > To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz = Bartolome > Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - = Realm, with absent Destination-Host >=20 > Hi MCruz >=20 > The proposed text applies to the realm report.=20 >=20 > Realm OLRs (in particular with same seq number) may be conveyed in = answers with different Origin-host (but with same Origin realm), so what = means to refer "to the Origin-Host AVP of the received message that = contained the (realm type) OC-OLR AVP". This is different from the Host = report, where the host type OC-OLR always refers to the origin host of = the answer. >=20 > Can you clarify and give a use case / topology case. >=20 > Best regards >=20 > JJacques >=20 >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan = Envoy=E9 : vendredi 5 septembre 2014 16:16 =C0 : dime@ietf.org; = draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com = Objet : Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - = Realm, with absent Destination-Host >=20 > I agree. >=20 > On 9/5/14, 2:40 AM, dime issue tracker wrote: >> #69: Report Type - Realm, with absent Destination-Host >>=20 >> In clause 6.6, host report was updated to add: >>=20 >> ... or the Destination-Host is >> not present in the request but the value of peer identity >> associated with the connection used to send the request = matches >> the value of the Origin-Host AVP of the received message that >> contained the OC-OLR AVP. >>=20 >> but this clarification needs to be included as well for realm = report. >>=20 >> Original text: >>=20 >> 1 A realm report. The overload treatment should apply to = requests >> for which all of the following conditions are true: >>=20 >> The Destination-Host AVP is absent in the request. >>=20 >> ... >>=20 >> Proposed text: >>=20 >> 1 A realm report. The overload treatment should apply to = requests >> for which all of the following conditions are true: >>=20 >> The Destination-Host AVP is absent in the request and the the = value >> of peer identity associated with the connection used to send the = request >> does not match the value of the Origin-Host AVP of the received = message >> that contained the OC-OLR AVP. >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_0895D03F-0F00-44AE-98BA-8EA7C334FFD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi = Ulrich,

I think I agree with your intent, but I = think the text has gotten more complicated than it needs to be. Here's a = proposed alternative:

In = 6.6:

0 A host report. The reacting node = applies overload abatement to the set of  "host-routed" requests = (see Section 3)  that would otherwise
be served = by a node with a Diameter-Identity that matches the Origin-Host AVP = value of the Diameter answer message
that = contained the report.

1 A realm = report. The reacting node applies overload abatement to the set of = "realm-routed" requests (see Section 3), where the
= Destination-Realm AVP value from the request matches the = Origin-Realm AVP value of the Diameter answer message = that 
contained the = report.

Then, replace the = 2nd and 3rd to last paragraphs and the last line of the 4th to last = paragraph of Section 3 with the = following:

This document defines report = types for overload of a specific server, and for overload of an entire = realm.

A request is = considered to be "host-routed" by a Diameter node if that node has = advance knowledge that the request will be served by a particular = destination. There are several ways a node can know this. For example, = the request could contain a Destination-Host AVP that matches the = destination. The sending node may perform final server selection.. Or = the sending node could be aware of some routing policy that will force a = request to go to the particular destination. (e.g., perhaps all requests = for a particular user go to a specific = server).

A request is = considered to be "realm-routed" by a Diameter node if that node does not = know the actual destination for the request. For example, the sending = node may forward the request to an agent, based on the routing table = entry for the request's application and realm. The sending node may have = no idea where the agent might forward the = request.

The distinction of = whether a given request is "host-routed" or "realm-routed" is from the = perspective of a particular node sending node. For example, a request = may be "realm-routed" from the perspective of the client, but = "host-routed" from the perspective of an agent that performs the final = server selection. In general, any "realm-routed" request will eventually = become a host-routed request as it traverses a Diameter = network.

A = report of type "host" is sent to request a reduction of offered load for = a specific server for the application-id indicated in the transaction. =  When receiving an OLR of type "host", a reacting node applies = overload abatement to host routed requests that would otherwise go to = the overloaded server.  The reacting node applies overload = abatement to the set of "host-routed" requests that the reacting node = knows will be served by the server that matches the Origin-Host AVP of = the message that contained = report.

A report type of = "realm" is sent to indicate the overload of all servers in a realm for = the application-id.  When receiving an OLR of type "realm", a = reacting node applies overload abatement to the set of "realm-routed" = requests destined for the realm indicate by the Origin-Realm AVP of the = message that contained the = report.



On Sep = 26, 2014, at 12:37 PM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> = wrote:

Mcruz, JJ,

Maybe I missed = your point, but my understanding is a bit different. 
Please see = the attached proposal.

Best = regards
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] = On Behalf Of ext Maria Cruz Bartolome
Sent: Friday, September 26, = 2014 11:58 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dime-ovli@t= ools.ietf.org
Subject: Re: [Dime] [dime] #69 = (draft-ietf-dime-ovli): Report Type - Realm, with absent = Destination-Host

Dear JJ, all

I think I understand your = concern.
I modified text in clause 6.6 to clarify this point. = Attached.
Let me know your opinions.
Best = regards
/MCruz


-----Original Message-----
From: = TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacque= s.trottin@alcatel-lucent.com] 
Sent: viernes, 26 de = septiembre de 2014 10:12
To: Maria Cruz Bartolome; dime@ietf.org; draft-ietf-dime-ovli@t= ools.ietf.org
Subject: RE: [Dime] [dime] #69 = (draft-ietf-dime-ovli): Report Type - Realm, with absent = Destination-Host


Hi Maria Cruz

1) The hereafter = proposed text  is in a sub part of section 6.6 addressing  the = overload treatment when the  OC-report type indicates realm report = so according to a Realm type OLR. The proposed  text mentions = "...Origin-Host AVP of the received message that contained the OC-OLR = AVP". This  OC-OLR AVP can be understood  as the Realm = type OLR subject of this section 6.6 subpart (this was my first = reading), but it is another report which is a host type OLR = generated by this peer. 
As you said we have to distinguish when = either a host or a realm report to be applied, so here the proposal is = to exclude from the text the case where the reacting node has an = active type Host type OLR of which the Origin Host match the peer = identity, as for this case the host type OLR will be applied. On = this basis I would propose write "Host type OC-OLR AVP" as hereafter. =   

"The Destination-Host AVP is absent in the request = and the value of peer identity associated with the connection used to = send the request does not match the value of the Origin-Host AVP of = a received message that contained a Host type OC-OLR AVP"

2) When = thinking a bit more to this case where the reacting node is directly = connected to the reporting node (eg a Client directly connected to two = or more servers, without intermediate DA, or a DA acting as a = reacting node directly connected to servers). The servers usually only = send Host type reports (I know there  is a  debate on = servers sending realm reports), so the reacting node will not receive = Realm reports.  For requests for which there is no destination = Host, the reacting node will select the peer according to the host OLRs =  it has or not for each of the peers (eg a peer that is = not overload or with a small overload )  and then apply the = abatement/throttling according to the Host type OLR of this peer. I = think we have the same understanding.     =   


Best = regards

JJacques 

-----Message d'origine-----
De : = Maria Cruz Bartolome [mailto:maria.cruz.bartol= ome@ericsson.com]
Envoy=E9 : jeudi 25 septembre 2014 18:28
=C0 = : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dime-ovli@t= ools.ietf.org
Objet : RE: [Dime] [dime] #69 = (draft-ietf-dime-ovli): Report Type - Realm, with absent = Destination-Host

Dear JJ,

I do not understand your = point.

Proposed clarification has the purpose to allow a reacting = node to distinguish when either a host or a realm report shall = apply.

Some time ago we based such a distinction on the presence = (meaning host report) or absence (meaning realm report).
Now we have = covered the case for host reports when the host is absent but it refers = to the directly connected peer. Therefore, just absence does = not allow the reacting node to identify it has to apply a realm = report.

Let me know if this clarifies, or if I may be missing = your point.
Thanks
/MCruz


-----Original = Message-----
From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacque= s.trottin@alcatel-lucent.com]
Sent: viernes, 12 de septiembre de = 2014 14:13
To: dime@ietf.org; draft-ietf-dime-ovli@t= ools.ietf.org; Maria Cruz Bartolome
Subject: RE: [Dime] [dime] = #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent = Destination-Host

Hi MCruz

The proposed  text applies = to the realm report. 

Realm OLRs (in particular with same = seq number) may be conveyed in answers with different Origin-host (but = with same Origin realm), so what means to refer "to the Origin-Host = AVP of the received message that contained the (realm type) OC-OLR AVP". = This is different  from the Host report, where the host type = OC-OLR always refers to the origin host  of the answer.

Can = you  clarify and give a use case / topology case.

Best = regards

JJacques


-----Message d'origine-----
De : = DiME [mailto:dime-bounces@ietf.org] = De la part de Steve Donovan Envoy=E9 : vendredi 5 septembre 2014 16:16 =C0= : dime@ietf.org; = draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@eri= csson.com Objet : Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): = Report Type - Realm, with absent Destination-Host

I = agree.

On 9/5/14, 2:40 AM, dime issue tracker = wrote:
#69: Report Type - Realm, with = absent Destination-Host

 In clause 6.6, host report was = updated to add:

 ... or the Destination-Host is
  =      not present in the request but the value of peer = identity
       associated with the connection = used to send the request matches
       the value = of the Origin-Host AVP of the received message that
    =    contained the OC-OLR AVP.

 but this = clarification needs to be included as well for realm = report.

 Original text:

    1  A realm = report.  The overload treatment should apply to requests
  =      for which all of the following conditions are = true:

       The Destination-Host AVP is = absent in the request.

      =  ...

 Proposed text:

    1  A = realm report.  The overload treatment should apply to = requests
       for which all of the following = conditions are true:

       The = Destination-Host AVP is absent in the request and the the = value
 of peer identity associated with the connection used to = send the request
 does not match the value of the Origin-Host = AVP of the received message
 that contained the OC-OLR = AVP.


_____________________________________________= __
DiME mailing list
DiME@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dime
<OC-Report-Type clause 6-6 = UW.docx>_______________________________________________
DiME = mailing = list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

= --Apple-Mail=_0895D03F-0F00-44AE-98BA-8EA7C334FFD5-- From nobody Wed Oct 15 22:54:01 2014 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 CF9231ACECE for ; Wed, 15 Oct 2014 22:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 c72JNRIPvRMg for ; Wed, 15 Oct 2014 22:53:58 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD951A9038 for ; Wed, 15 Oct 2014 22:53:57 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-ee-543f5d73eaf6 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 74.1A.04081.37D5F345; Thu, 16 Oct 2014 07:53:55 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.19]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 07:53:54 +0200 From: Maria Cruz Bartolome To: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" , "srdonovan@usdonovans.com" Thread-Topic: [Dime] [dime] #77 (draft-ietf-dime-ovli): Section 4.2.3 - Reporting node behavior (overload report handling) Thread-Index: AQHP5yfajxBbxUJzh06xjh8+ZAmIcpwxPa5g Date: Thu, 16 Oct 2014 05:53:54 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209842F69@ESESSMB101.ericsson.se> References: <066.d4c405dbb2245ca94afc738db13a2a20@trac.tools.ietf.org> In-Reply-To: <066.d4c405dbb2245ca94afc738db13a2a20@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+JvjW5xrH2IweH1ohZze1ewWSw/3sBs saGJx4HZY8mSn0weXy5/ZvNY9baPNYA5issmJTUnsyy1SN8ugSvj9/OLjAUveCp6dl9ga2Cc y9XFyMkhIWAiseldNwuELSZx4d56ti5GLg4hgaOMEne232OGcBYzSrT2P2QCqWITsJO4dPoF E0hCRGA1o8SFI4eYQRLCAtUSy+6cYAWxRQRqJBrafzFD2EYSm2fNAGtmEVCVuH3pHlgNr4Cv RNPe0+xdjBxAG9wk/n9QBzE5Bdwlvk83AalgBDro+6k1YJ3MAuISt57MZ4I4VEBiyZ7zzBC2 qMTLx/9YIWwlicYlT1gh6nUkFuz+xAZha0ssW/iaGWKroMTJmU9YJjCKzkIydhaSlllIWmYh aVnAyLKKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzByDm75bbCD8eVzx0OMAhyMSjy8Cldt Q4RYE8uKK3MPMUpzsCiJ8y48Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6NnyMu1Pnsu xV3N5pnpk/ThI8Pe3NOTmJqE5x0yXezwTuC2zhyjhaprNEPU+ZqNMiyMlqq/PcfH5nr+y1Pb 5WxNcp5MbyTnNs1qOdR2IOeUn4Prx82iTxZNUvA9+tNWTYLFjDkt5wK7Ts2ySuna6tXWm36u CQrtZf+dmZhSf/bv1MCbX8x/1SqxFGckGmoxFxUnAgD1hdq6fQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gSC8kHe24iD6ngI2ywAppMUb1uo Subject: Re: [Dime] [dime] #77 (draft-ietf-dime-ovli): Section 4.2.3 - Reporting node behavior (overload report handling) 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, 16 Oct 2014 05:54:00 -0000 Hello Steve, See below Thanks -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker Sent: lunes, 13 de octubre de 2014 22:54 To: draft-ietf-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #77 (draft-ietf-dime-ovli): Section 4.2.3 - Reportin= g node behavior (overload report handling) #77: Section 4.2.3 - Reporting node behavior (overload report handling) Propose adding the following two paragraphs after the third paragraph (lo= cation isn't critically important): The reporting node MUST include the OC-Validity-Duration AVP in the OL= R. [MCruz] There is a default value in ch. 6.5. No need to set this AVP explic= itly. The reporting node MUST include a report-type in the OLR. --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Wed Oct 15 22:54:04 2014 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 942C71A9038 for ; Wed, 15 Oct 2014 22:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 a-gY7bOMDtys for ; Wed, 15 Oct 2014 22:53:59 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52D91ACECB for ; Wed, 15 Oct 2014 22:53:58 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-f3-543f5d74d4ea Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 15.1A.04081.47D5F345; Thu, 16 Oct 2014 07:53:56 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.19]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 07:53:55 +0200 From: Maria Cruz Bartolome To: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" , "srdonovan@usdonovans.com" Thread-Topic: [Dime] [dime] #82 (draft-ietf-dime-ovli): 6.4. OC-Sequence-Number AVP Thread-Index: AQHP5ymn/w6VJ61jM0+TGs95UnnjkJwxPi/g Date: Thu, 16 Oct 2014 05:53:55 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209842F71@ESESSMB101.ericsson.se> References: <066.d3ed74d24b21e564d1e8254e3d1cbd6d@trac.tools.ietf.org> In-Reply-To: <066.d3ed74d24b21e564d1e8254e3d1cbd6d@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+JvjW5JrH2IwZ+DZhZze1ewWSw/3sBs saGJx4HZY8mSn0weXy5/ZvNY9baPNYA5issmJTUnsyy1SN8ugSvjze4rbAVz+Cu6D/9ja2Ds 5uli5OSQEDCRuL9sJSOELSZx4d56ti5GLg4hgaOMEkse9jFDOIsZJXbe6mQCqWITsJO4dPoF E0hCRGA1o8SFI4eAqjg4hAVCJLbfFgepEREIlVj8uZcZwjaS+PRjLztICYuAqsS2mwEgJq+A r8TKjjCQCiEBN4nbzQfYQWxOAXeJmb0PWUFsRqB7vp9aA7aVWUBc4taT+UwQdwpILNlznhnC FpV4+fgfK4StJNG45AkrRL2OxILdn9ggbG2JZQtfg9XzCghKnJz5hGUCo+gsJGNnIWmZhaRl FpKWBYwsqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjEC4+bglt8GOxhfPnc8xCjAwajEw6tw 1TZEiDWxrLgy9xCjNAeLkjjvwnPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwMq+rPTh/ BdedX3rvJ2nnrVxV0WM58477ylouPh2+Ywt8P9g9YpL42bb+2Jozu7vm5VXUH9j69fvFls92 H685nolZ8GHzrty3bsarWCODpmwUyIn22f0poDv8fPH3DoV5RzZPnSArHrdlqjU32713Xpd+ fzBz33RgFof/hQslxjoyDn+S/3h2SiqxFGckGmoxFxUnAgBX+g6PfAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1YwqHUlGkQV_gHW57h0k__AgbvQ Subject: Re: [Dime] [dime] #82 (draft-ietf-dime-ovli): 6.4. OC-Sequence-Number 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: Thu, 16 Oct 2014 05:54:00 -0000 Hello Steve, See below please /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker Sent: lunes, 13 de octubre de 2014 23:07 To: draft-ietf-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com Cc: dime@ietf.org Subject: [Dime] [dime] #82 (draft-ietf-dime-ovli): 6.4. OC-Sequence-Number = AVP #82: 6.4. OC-Sequence-Number AVP Propose modifying the second paragraph: Before: From the functionality point of view, the OC-Sequence-Number AVP MUST be used as a non-volatile increasing counter between two DOIC nodes. After: From the functionality point of view, the OC-Sequence-Number AVP MUST be used as a non-volatile increasing counter for an individual overload= report between two DOIC nodes. Also propose adding the following paragraph at the end of the section: The sequence number is not required to be greater between discrete overlo= ad reports. [MCruz] Not sure what do you mean by "discrete" OLR? Either they are diffe= rent (higher sequence numbers) or they are same (same sequence number, or? --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Thu Oct 16 14:46:03 2014 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 04ED91A8AC1 for ; Thu, 16 Oct 2014 14:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6IKC9vs30A-2 for ; Thu, 16 Oct 2014 14:45:55 -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 48B411A8AC2 for ; Thu, 16 Oct 2014 14:45:55 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:56780 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xesrj-0002rt-Ei; Thu, 16 Oct 2014 14:45:53 -0700 Message-ID: <54403C8C.2050108@usdonovans.com> Date: Thu, 16 Oct 2014 23:45:48 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Maria Cruz Bartolome , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" References: <066.d4c405dbb2245ca94afc738db13a2a20@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209842F69@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B9209842F69@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dAcL4e9RbWWM-Ppsxyqk7BlHjlE Subject: Re: [Dime] [dime] #77 (draft-ietf-dime-ovli): Section 4.2.3 - Reporting node behavior (overload report handling) 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, 16 Oct 2014 21:45:56 -0000 Maria Cruz, The OC-Validity-Duration is defined in the OC-OLR syntax as being required. As a result, we should remove the default value statement. Ben has also pointed out that these two statements below are not needed because it is already defined in the OC-OLR syntax. Steve On 10/16/14, 7:53 AM, Maria Cruz Bartolome wrote: > Hello Steve, > > See below > Thanks > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker > Sent: lunes, 13 de octubre de 2014 22:54 > To: draft-ietf-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com > Cc: dime@ietf.org > Subject: [Dime] [dime] #77 (draft-ietf-dime-ovli): Section 4.2.3 - Reporting node behavior (overload report handling) > > #77: Section 4.2.3 - Reporting node behavior (overload report handling) > > Propose adding the following two paragraphs after the third paragraph (location isn't critically important): > > The reporting node MUST include the OC-Validity-Duration AVP in the OLR. > [MCruz] There is a default value in ch. 6.5. No need to set this AVP explicitly. > > The reporting node MUST include a report-type in the OLR. > From nobody Fri Oct 17 06:04:18 2014 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 873311ACD86 for ; Fri, 17 Oct 2014 06:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdEl-GcMledL for ; Fri, 17 Oct 2014 06:04:03 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0818D1ACD85 for ; Fri, 17 Oct 2014 06:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51986; q=dns/txt; s=iport; t=1413551042; x=1414760642; h=message-id:date:from:mime-version:to:subject; bh=/XDCYadnBtgVpVNpzpP/faIXEsPYAKAVQgfJ/E1ozYA=; b=dxCubnomLtPVVGx1Cocb4hGx0NQKaSPF/3ca/iF50XqRlOaunvQ+egU2 yDV/LXQnCFXSYKZmrMBVtzAukUEClan8zZxMclYUhqttJG8kLf/kij25G R899V9lupJB0+oGe4ktahWQOqYBiRYw328Fssb5xNizKNj188ejv2FPE+ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAEAGQSQVRIo8UY/2dsb2JhbABbgkiBcYhhzFoBfYQ2Sz0WAQEWAwIBAgFLDQgBAReIJKcYpDMBAQEHAQEBAQEBHJUfBZ1ZgTCDRoJyjjSDeTsvgksBAQE X-IronPort-AV: E=Sophos; i="5.04,739,1406592000"; d="scan'208,217"; a="46209579" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 17 Oct 2014 13:03:59 +0000 Received: from [10.86.240.167] (che-vpn-cluster-1-167.cisco.com [10.86.240.167]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9HD3neL004406 for ; Fri, 17 Oct 2014 13:03:51 GMT Message-ID: <5440F0D5.2000203@cisco.com> Date: Fri, 17 Oct 2014 12:35:01 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: dime mailing list Content-Type: multipart/alternative; boundary="------------090304040808060403040201" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Ei7Cn_5G4DT1toA9cE4zML00RfA Subject: [Dime] draft-ietf-dime-ovli-04.txt: feedback 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, 17 Oct 2014 13:04:07 -0000 This is a multi-part message in MIME format. --------------090304040808060403040201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is some feedback on draft-ietf-dime-ovli-04.txt. Note that some of it might overlap with what was discussed during the interim meeting during these 2 days. - Note that the overload control solution defined in this specification does not address all the requirements listed in [RFC7068]. A number of overload control related features are left for the future specifications. You have to be more specific on which requirements this document support, and why a subset is only supported. Can you please open an issue tracker for this (not Internet connectivity right now) - OLD: Furthermore, the solution is designed to apply to existing and future Diameter applications, requires no changes to the Diameter base protocol [RFC6733] and is deployable in environments where some Diameter nodes do not implement the Diameter overload control solution defined in this specification. NEW: Furthermore, the solution, _which is _designed to apply to existing and future Diameter applications, requires no changes to the Diameter base protocol [RFC6733] and is deployable in environments where some Diameter nodes do not implement the Diameter overload control solution defined in this specification. - Abatement Algorithm An algorithm requested by reporting nodes and used by reacting nodes to reduce the amount of traffic sent during an occurrence of overload control. I think the reporting nodes request a mechanism, not an algorithm. Proposal: Abatement Algorithm A _mechanism _requested by reporting nodes and used by reacting nodes to reduce the amount of traffic sent during an occurrence of overload control. Alternate proposal: An algorithm _initiated _by reporting nodes and used by reacting nodes to reduce the amount of traffic sent during an occurrence of overload control. - Terminology: It would be beneficial if you would tell which RFC 6733 terms you use in this document, and be consistent with those. Also, be consistent throughout the draft regarding capitalized terms. Example: RFC 6733 speaks of Diameter Client/Server. This document speaks sometimes client, Diameter client, Diameter Client - OLD: Reacting Node A Diameter node that consumes and acts upon a report. NEW: Reacting Node A Diameter node that consumes and acts upon _an overload report._ - OLD: Reacting nodes indicate support for DOIC by including the OC- Supported-Features AVP all request messages originated or relayed by the Diameter node. NEW: Reacting nodes indicate support for DOIC by including the OC- Supported-Features AVP _in _all request messages originated or relayed by the Diameter node. - I've been confused by the "Loss Algorithm" name, which is really about a "percentage reduction". If you have in the future a "rate reduction" algorithm, how will you call this one? - There are multiple sections discussing the same topic, for example the default value for the OC-Validity-Duration. Section 6.3 The default value for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds) Section 6.4, The default value for the OC-Validity-Duration AVP is 5 (i.e., 5 seconds). - There are multiple sections discussing the same topic, for example M-bit covered in section 4.3 (normative) More specifically, the sub-AVPs inside the OC-Supported-Features and OC-OLR AVP MAY have the M-bit set. covered in section 6. Attribute Value Pairs (Normative) When added to existing commands, both OC-Feature-Vector and OC-OLR AVPs SHOULD have the M-bit flag cleared to avoid backward compatibility issues. covered in 6.8. Attribute Value Pair flag rules The Diameter overload control AVPs SHOULD always be sent with the M-bit cleared when used within existing Diameter applications to avoid backward compatibility issues. I believe that the document will be clearer with a single normative section discussing one topic. Btw, that's a generic comment at this point: the draft looks like a series of edits, and would be benefit from an editorial/consistency pass. - OC-OLR AVPs with unknown values SHOULD be silently discarded and the event SHOULD be logged. What do you mean by "OC-OLR AVPs with unknown values"? Unknown to whom? * Do you mean "out of range", like OC-Reduction-Percentage of 101 % (for Integer32) If yes, this is covered already: The value of the Reduction-Percentage AVP is between zero (0) and one hundred (100). Values greater than 100 are ignored * Do you mean "not assigned", like OC-report-type value of 2, which doesn't exist Note: section 6.7 should point to IANA, I guess - I believe that the IANA considerations "AVP codes" section 8.1 should be extended. Take an existing RFC as an example. Regards, Benoit --------------090304040808060403040201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Here is some feedback on draft-ietf-dime-ovli-04.txt.
Note that some of it might overlap with what was discussed during the interim meeting during these 2 days.

-
Note that the overload control solution defined in this
specification does not address all the requirements listed in
[RFC7068]. A number of overload control related features are left
for the future specifications.

You have to be more specific on which requirements this document support, and why a subset is only supported.
Can you please open an issue tracker for this (not Internet connectivity right now)

- OLD:
Furthermore, the solution is designed to apply to existing
and future Diameter applications, requires no changes to the Diameter
base protocol [RFC6733] and is deployable in environments where some
Diameter nodes do not implement the Diameter overload control
solution defined in this specification.

NEW:
Furthermore, the solution, which is designed to apply to existing
and future Diameter applications, requires no changes to the Diameter
base protocol [RFC6733] and is deployable in environments where some
Diameter nodes do not implement the Diameter overload control
solution defined in this specification.

-
Abatement Algorithm
An algorithm requested by reporting nodes and used by reacting
nodes to reduce the amount of traffic sent during an occurrence of
overload control.

I think the reporting nodes request a mechanism, not an algorithm.
Proposal:
Abatement Algorithm
A mechanism requested by reporting nodes and used by reacting
nodes to reduce the amount of traffic sent during an occurrence of
overload control.

Alternate proposal:
An algorithm initiated by reporting nodes and used by reacting
nodes to reduce the amount of traffic sent during an occurrence of
overload control.

- Terminology:
It would be beneficial if you would tell which RFC 6733 terms you use in this document, and be consistent with those.
Also, be consistent throughout the draft regarding capitalized terms.
Example: RFC 6733 speaks of Diameter Client/Server. This document speaks sometimes client, Diameter client, Diameter Client

-
OLD:
Reacting Node
A Diameter node that consumes and acts upon a report.

NEW:
Reacting Node
A Diameter node that consumes and acts upon an overload report.

- OLD:
Reacting nodes indicate support for DOIC by including the OC-
Supported-Features AVP all request messages originated or relayed by
the Diameter node.

NEW:
Reacting nodes indicate support for DOIC by including the OC-
Supported-Features AVP in all request messages originated or relayed by
the Diameter node.

- I've been confused by the "Loss Algorithm" name, which is really about a "percentage reduction".
If you have in the future a "rate reduction" algorithm, how will you call this one?

- There are multiple sections discussing the same topic, for example the default value for the OC-Validity-Duration.
Section 6.3
The default value for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds)
Section 6.4,
The default value for the OC-Validity-Duration AVP is 5 (i.e., 5 seconds).

- There are multiple sections discussing the same topic, for example M-bit
covered in section 4.3 (normative)
More specifically, the sub-AVPs inside the OC-Supported-Features and OC-OLR AVP MAY have the M-bit set.
covered in section 6. Attribute Value Pairs (Normative)
When added to existing commands, both OC-Feature-Vector and OC-OLR
AVPs SHOULD have the M-bit flag cleared to avoid backward
compatibility issues.
covered in 6.8. Attribute Value Pair flag rules
The Diameter overload control AVPs SHOULD always be sent with the
M-bit cleared when used within existing Diameter applications to
avoid backward compatibility issues.
I believe that the document will be clearer with a single normative section discussing one topic.
Btw, that's a generic comment at this point: the draft looks like a series of edits, and would be benefit from an editorial/consistency pass.

-
OC-OLR AVPs with unknown values SHOULD be silently discarded and the event SHOULD
be logged.

What do you mean by "OC-OLR AVPs with unknown values"?   Unknown to whom?
* Do you mean "out of range", like OC-Reduction-Percentage of 101 % (for Integer32)
If yes, this is covered already:
The value of the Reduction-Percentage AVP is between zero (0) and one hundred (100). Values greater than 100 are ignored
* Do you mean "not assigned", like OC-report-type value of 2, which doesn't exist
Note: section 6.7 should point to IANA, I guess

- I believe that the IANA considerations "AVP codes" section 8.1 should be extended.
Take an existing RFC as an example.
       
Regards, Benoit
--------------090304040808060403040201-- From nobody Sun Oct 19 23:34:43 2014 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 5503B1A1BEC for ; Sun, 19 Oct 2014 23:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-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 sfHOp82Yo5iF for ; Sun, 19 Oct 2014 23:34:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 39E651A0378 for ; Sun, 19 Oct 2014 23:34:41 -0700 (PDT) Received: from localhost ([::1]:56108 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xg6Y9-0003vF-4Z; Sun, 19 Oct 2014 23:34:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 06:34:37 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/60#comment:3 Message-ID: <081.8a4914202a082ba41dbfb5fcf78d6d96@trac.tools.ietf.org> References: <066.25846a096050f4de0dae76f80a0a9d46@trac.tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <066.25846a096050f4de0dae76f80a0a9d46@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/250jniaBBv9Rvwjh0ymeCDLo87g Cc: dime@ietf.org Subject: Re: [Dime] [dime] #60 (draft-ietf-dime-ovli): Agent Overload Report Handling considerations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 06:34:42 -0000 #60: Agent Overload Report Handling considerations Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of issue #23. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: duplicate Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Sun Oct 19 23:35:32 2014 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 D0B861A0378 for ; Sun, 19 Oct 2014 23:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oOi3gMDPkvzW for ; Sun, 19 Oct 2014 23:35:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 C15931A6FA0 for ; Sun, 19 Oct 2014 23:35:29 -0700 (PDT) Received: from localhost ([::1]:56176 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xg6Yw-0004S3-8t; Sun, 19 Oct 2014 23:35:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 06:35:26 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/61#comment:3 Message-ID: <081.38c5168434f7e918638ab5473ef56547@trac.tools.ietf.org> References: <066.240dbe9c6b177a4db5db4535d22df5f1@trac.tools.ietf.org> X-Trac-Ticket-ID: 61 In-Reply-To: <066.240dbe9c6b177a4db5db4535d22df5f1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/96T-yKOuyzvaXcPtqbz8ikmIiMk Cc: dime@ietf.org Subject: Re: [Dime] [dime] #61 (draft-ietf-dime-ovli): Agent Capability Announcement Considerations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 06:35:31 -0000 #61: Agent Capability Announcement Considerations Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of issue #23. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: duplicate Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Sun Oct 19 23:38:15 2014 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 F0B6A1A6FD4 for ; Sun, 19 Oct 2014 23:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 X0ZYMsH3HsBp for ; Sun, 19 Oct 2014 23:38:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 A18081A6FCA for ; Sun, 19 Oct 2014 23:38:07 -0700 (PDT) Received: from localhost ([::1]:56301 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xg6bU-00060T-UT; Sun, 19 Oct 2014 23:38:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 06:38:04 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/85#comment:1 Message-ID: <081.59481ca83ddcf9ab4a68dda3859e21ec@trac.tools.ietf.org> References: <066.8ce734c1c66c770a886774c6bf72f7be@trac.tools.ietf.org> X-Trac-Ticket-ID: 85 In-Reply-To: <066.8ce734c1c66c770a886774c6bf72f7be@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/h8HyI6YAdM5SDDWswbk-bOuQJuQ Cc: dime@ietf.org Subject: Re: [Dime] [dime] #85 (draft-ietf-dime-ovli): New error response X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 06:38:13 -0000 #85: New error response Comment (by srdonovan@usdonovans.com): Raw notes taken from discussion at interim meeting: Requirements • Current Too-Busy behavior allows for retry • Too-Busy was originally defined to have a per connection scope • MUST only be used when a specific server exists o This might mean that Too-Busy cannot be used for the throttle error without updating the definition of Too-Busy behavior • Unable-to-deliver might be another alternative for throttling behavior • Need new error response behavior – DOIC needs error response behavior to prevent retries due to the message being throttled. • Need to handle case where transaction client supports the throttling error behavior and for transaction clients that do not support the throttling error behavior. Proposal: Use Unable-to-Comply error code when throttling by agent, too- busy when throttling by server Use case where agent is reacting node – throttled messages should result in Unable-to-Comply Use case – agent throttling when client supports DOIC unable-to-comply also works Use case – Server throttling – too-busy works Could add optional “error-diagnostic AVP†to indicate the reason for unable-to-comply – should be addressed in a separate RFC -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Sun Oct 19 23:44:11 2014 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 270AD1A6FB0 for ; Sun, 19 Oct 2014 23:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 v6r2ZoHo6xBn for ; Sun, 19 Oct 2014 23:44:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 186361A6FAE for ; Sun, 19 Oct 2014 23:44:09 -0700 (PDT) Received: from localhost ([::1]:56520 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xg6hK-0006vM-Qp; Sun, 19 Oct 2014 23:44:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 06:44:06 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/57#comment:2 Message-ID: <081.96c9cb2385d71963616bbf115ebd0551@trac.tools.ietf.org> References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GB6dEa2-7WNF6qhbhO5TBao6o7Q Cc: dime@ietf.org Subject: Re: [Dime] [dime] #57 (draft-ietf-dime-ovli): Handling of "Realm-Routed" Overload report type X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 06:44:10 -0000 #57: Handling of "Realm-Routed" Overload report type Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => invalid Comment: Consensus was reached to stay with two report types, host and realm. The definition of these two report types is defined in #23. As a result, the concept of a "realm-routed" report type is covered by the realm report and the concept of a realm report that covers all requests to the realm, independent of request type, was left for a potential future extension. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: invalid Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 00:03:23 2014 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 2CD8B1A1BF8 for ; Mon, 20 Oct 2014 00:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0KK_aSrhCKA1 for ; Mon, 20 Oct 2014 00:03:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 6C5D81A6FC3 for ; Mon, 20 Oct 2014 00:03:16 -0700 (PDT) Received: from localhost ([::1]:57820 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xg6zo-0002tv-Kv; Mon, 20 Oct 2014 00:03:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 07:03:12 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/77#comment:1 Message-ID: <081.85e4d7195d716ffbdc495e2ecfb3d633@trac.tools.ietf.org> References: <066.d4c405dbb2245ca94afc738db13a2a20@trac.tools.ietf.org> X-Trac-Ticket-ID: 77 In-Reply-To: <066.d4c405dbb2245ca94afc738db13a2a20@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QUK8NDutLMUvpBaEPYsoZt44IX0 Cc: dime@ietf.org Subject: Re: [Dime] [dime] #77 (draft-ietf-dime-ovli): Section 4.2.3 - Reporting node behavior (overload report handling) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 07:03:20 -0000 #77: Section 4.2.3 - Reporting node behavior (overload report handling) Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => invalid Comment: Agreed to close with no change as these requirements are already addressed in the syntax definition. Reaffirmed consensus on report-type being required due to the need for it to be used by a reporting node to help differentiate reports when there are multiple in a message. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: invalid Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 01:10:32 2014 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 0166C1A6FDA for ; Mon, 20 Oct 2014 01:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 b_ClGLQZJieK for ; Mon, 20 Oct 2014 01:01:31 -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 7A4CC1A6FD9 for ; Mon, 20 Oct 2014 01:01:31 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:50304 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xg7uD-0009CO-Cq for dime@ietf.org; Mon, 20 Oct 2014 01:01:31 -0700 Message-ID: <5444C157.6010809@usdonovans.com> Date: Mon, 20 Oct 2014 10:01:27 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------000004040007010809070201" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/aKPbsOBgAjJNB6xkpjG6qQfgJgk X-Mailman-Approved-At: Mon, 20 Oct 2014 01:10:28 -0700 Subject: [Dime] Change to -04 version - removed document restructuring information 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, 20 Oct 2014 08:01:41 -0000 This is a multi-part message in MIME format. --------------000004040007010809070201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, I have removed the appendix that showed the mapping used to restructure the document. I also removed the normative, non normative indicators in the section headers that were added to aid in the understanding of the restructuring. This change has been checked into github. I have also attached the diff resulting from this change. I will be occasionally attaching a diff to checkpoint changes made up to that point. Regards, Steve --------------000004040007010809070201 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed. Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed.
Internet-Draft Broadcom Internet-Draft Broadcom
Intended status: Standards Track S. Donovan, Ed. Intended status: Standards Track S. Donovan, Ed.
Expires: April 12, 2015 B. Campbell Expires: April 23, 2015 B. Campbell
Oracle Oracle
L. Morand L. Morand
Orange Labs Orange Labs
October 9, 2014 October 20, 2014
Diameter Overload Indication Conveyance Diameter Overload Indication Conveyance
draft-ietf-dime-ovli-04.txt draft-ietf-dime-ovli-04.txt
Abstract Abstract
This specification documents a Diameter Overload Control (DOC) base This specification documents a Diameter Overload Control (DOC) base
solution and the dissemination of the overload report information. solution and the dissemination of the overload report information.
Requirements Requirements
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 12, 2015. This Internet-Draft will expire on April 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Piggybacking Principle (Non normative) . . . . . . . . . 6 3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 6
3.2. DOIC Capability Announcement (Non normative) . . . . . . 7 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7
3.3. DOIC Overload Condition Reporting (Non normative) . . . . 9 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 9
3.4. DOIC Extensibility (Non normative) . . . . . . . . . . . 10 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10
3.5. Simplified Example Architecture (Non normative) . . . . . 10 3.5. Simplified Example Architecture . . . . . . . . . . . . . 10
3.6. Considerations for Applications Integrating the DOIC 3.6. Considerations for Applications Integrating the DOIC
Solution (Non normative) . . . . . . . . . . . . . . . . 11 Solution . . . . . . . . . . . . . . . . . . . . . . . . 11
3.6.1. Application Classification (Non normative) . . . . . 11 3.6.1. Application Classification . . . . . . . . . . . . . 11
3.6.2. Application Type Overload Implications (Non 3.6.2. Application Type Overload Implications . . . . . . . 12
normative) . . . . . . . . . . . . . . . . . . . . . 12 3.6.3. Request Transaction Classification . . . . . . . . . 14
3.6.3. Request Transaction Classification (Non normative) . 14 3.6.4. Request Type Overload Implications . . . . . . . . . 14
3.6.4. Request Type Overload Implications (Non normative) . 14 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 16
4. Solution Procedures (Normative) . . . . . . . . . . . . . . . 16 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 16
4.1. Capability Announcement (Normative) . . . . . . . . . . . 16 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 16
4.1.1. Reacting Node Behavior (Normative) . . . . . . . . . 16 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 17
4.1.2. Reporting Node Behavior (Normative) . . . . . . . . 17 4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 18
4.1.3. Agent Behavior (Normative) . . . . . . . . . . . . . 18 4.2. Overload Report Processing . . . . . . . . . . . . . . . 18
4.2. Overload Report Processing (Normative) . . . . . . . . . 18 4.2.1. Overload Control State . . . . . . . . . . . . . . . 18
4.2.1. Overload Control State (Normative) . . . . . . . . . 18 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 20
4.2.2. Reacting Node Behavior (Normative) . . . . . . . . . 20 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 22
4.2.3. Reporting Node Behavior (Normative) . . . . . . . . 22 4.2.4. Agent Behavior . . . . . . . . . . . . . . . . . . . 22
4.2.4. Agent Behavior (Normative) . . . . . . . . . . . . . 22 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 23
4.3. Protocol Extensibility (Normative) . . . . . . . . . . . 23 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 24
5. Loss Algorithm (Normative) . . . . . . . . . . . . . . . . . 24 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Overview (Non normative) . . . . . . . . . . . . . . . . 24
5.2. Use of OC-Reduction-Percentage AVP . . . . . . . . . . . 25 5.2. Use of OC-Reduction-Percentage AVP . . . . . . . . . . . 25
5.3. Reporting Node Behavior (Normative) . . . . . . . . . . . 25 5.3. Reporting Node Behavior . . . . . . . . . . . . . . . . . 25
5.4. Reacting Node Behavior (Normative) . . . . . . . . . . . 25 5.4. Reacting Node Behavior . . . . . . . . . . . . . . . . . 25
6. Attribute Value Pairs (Normative) . . . . . . . . . . . . . . 26 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 26
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 27 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 27
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 27 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 27
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 28 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 28
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 29 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 29
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 29 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 29
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 30 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 30
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 31 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 31
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 31 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 31
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 32 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
skipping to change at page 3, line 26 skipping to change at page 3, line 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 36 11.1. Normative References . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 37 11.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Issues left for future specifications . . . . . . . 37 Appendix A. Issues left for future specifications . . . . . . . 37
A.1. Additional traffic abatement algorithms . . . . . . . . . 37 A.1. Additional traffic abatement algorithms . . . . . . . . . 37
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 37 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 37
A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 38 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 38
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 38 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 38
B.1. Mix of Destination-Realm routed requests and Destination- B.1. Mix of Destination-Realm routed requests and Destination-
Host routed requests . . . . . . . . . . . . . . . . . . 38 Host routed requests . . . . . . . . . . . . . . . . . . 38
Appendix C. Restructuring of -02 version of the draft . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This specification defines a base solution for Diameter Overload This specification defines a base solution for Diameter Overload
Control (DOC), refered to as Diameter Overload Indication Conveyance Control (DOC), refered to as Diameter Overload Indication Conveyance
(DOIC). The requirements for the solution are described and (DOIC). The requirements for the solution are described and
discussed in the corresponding design requirements document discussed in the corresponding design requirements document
[RFC7068]. Note that the overload control solution defined in this [RFC7068]. Note that the overload control solution defined in this
specification does not address all the requirements listed in specification does not address all the requirements listed in
[RFC7068]. A number of overload control related features are left [RFC7068]. A number of overload control related features are left
skipping to change at page 6, line 47 skipping to change at page 6, line 42
that are "adjacent" for DOIC purposes may not be adjacent from a that are "adjacent" for DOIC purposes may not be adjacent from a
Diameter, or transport, perspective. For example, one or more Diameter, or transport, perspective. For example, one or more
Diameter agents that do not support DOIC may exist between a given Diameter agents that do not support DOIC may exist between a given
pair of reporting and reacting nodes, as long as those agents pass pair of reporting and reacting nodes, as long as those agents pass
unknown AVPs through unmolested. The report types described in this unknown AVPs through unmolested. The report types described in this
document can safely pass through non-supporting agents. This may not document can safely pass through non-supporting agents. This may not
be true for report types defined in future specifications. Documents be true for report types defined in future specifications. Documents
that introduce new report types MUST describe any limitations on that introduce new report types MUST describe any limitations on
their use across non-supporting agents. their use across non-supporting agents.
3.1. Piggybacking Principle (Non normative) 3.1. Piggybacking Principle
The overload control AVPs defined in this specification have been The overload control AVPs defined in this specification have been
designed to be piggybacked on top of existing application message designed to be piggybacked on top of existing application message
exchanges. This is made possible by adding overload control top exchanges. This is made possible by adding overload control top
level AVPs, the OC-OLR AVP and the OC-Supported-Features AVP as level AVPs, the OC-OLR AVP and the OC-Supported-Features AVP as
optional AVPs into existing commands when the corresponding Command optional AVPs into existing commands when the corresponding Command
Code Format (CCF) specification allows adding new optional AVPs (see Code Format (CCF) specification allows adding new optional AVPs (see
Section 1.3.4 of [RFC6733]). Section 1.3.4 of [RFC6733]).
Reacting nodes indicate support for DOIC by including the OC- Reacting nodes indicate support for DOIC by including the OC-
skipping to change at page 7, line 31 skipping to change at page 7, line 27
Note that the overload control solution does not have fixed server Note that the overload control solution does not have fixed server
and client roles. The DOIC node role is determined based on the and client roles. The DOIC node role is determined based on the
message type: whether the message is a request (i.e. sent by a message type: whether the message is a request (i.e. sent by a
"reacting node") or an answer (i.e. send by a "reporting node"). "reacting node") or an answer (i.e. send by a "reporting node").
Therefore, in a typical "client-server" deployment, the "client" MAY Therefore, in a typical "client-server" deployment, the "client" MAY
report its overload condition to the "server" for any server report its overload condition to the "server" for any server
initiated message exchange. An example of such is the server initiated message exchange. An example of such is the server
requesting a re-authentication from a client. requesting a re-authentication from a client.
3.2. DOIC Capability Announcement (Non normative) 3.2. DOIC Capability Announcement
The DOIC solutions supports the ability for Diameter nodes to The DOIC solutions supports the ability for Diameter nodes to
determine if other nodes in the path of a request support the determine if other nodes in the path of a request support the
solution. This capability is refered to as DOIC Capability solution. This capability is refered to as DOIC Capability
Announcement (DCA) and is separate from Diameter Capability Exchange. Announcement (DCA) and is separate from Diameter Capability Exchange.
The DCA mechanism is built around the piggybacking principle used for The DCA mechanism is built around the piggybacking principle used for
transporting Diameter overload AVPs. This includes both DCA AVPs and transporting Diameter overload AVPs. This includes both DCA AVPs and
AVPs associated with Diameter overload reports. This allows for the AVPs associated with Diameter overload reports. This allows for the
DCA AVPs to be carried across Diameter nodes that do not support the DCA AVPs to be carried across Diameter nodes that do not support the
skipping to change at page 9, line 5 skipping to change at page 9, line 5
path of a request differ. In this case, the agent updates the OC- path of a request differ. In this case, the agent updates the OC-
Supported-Feature AVP to reflect the mixture of the two sets of Supported-Feature AVP to reflect the mixture of the two sets of
supported features. supported features.
The logic to determine the content of the modified OC-Supported- The logic to determine the content of the modified OC-Supported-
Feature AVP is out-of-scope for this specification and is left to Feature AVP is out-of-scope for this specification and is left to
implementation decisions. Care must be taken in doing so not to implementation decisions. Care must be taken in doing so not to
introduce interoperability issues for downstream or upstream DOIC introduce interoperability issues for downstream or upstream DOIC
nodes. nodes.
3.3. DOIC Overload Condition Reporting (Non normative) 3.3. DOIC Overload Condition Reporting
As with DOIC Capability Announcement, Overload Condition Reporting As with DOIC Capability Announcement, Overload Condition Reporting
uses new AVPs (Section 6.3) to indicate an overload condition. uses new AVPs (Section 6.3) to indicate an overload condition.
The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP
includes the type of report, an overload report ID, the length of includes the type of report, an overload report ID, the length of
time that the report is valid and abatement algorithm specific AVPs. time that the report is valid and abatement algorithm specific AVPs.
Two types of overload reports are defined in this document, host Two types of overload reports are defined in this document, host
reports and realm reports. reports and realm reports.
skipping to change at page 10, line 16 skipping to change at page 10, line 16
change the reporting node can send new overload reports requesting change the reporting node can send new overload reports requesting
greater reduction if the condition gets worse or less reduction if greater reduction if the condition gets worse or less reduction if
the condition improves. The reporting node sends an overload report the condition improves. The reporting node sends an overload report
with a duration of zero to indicate that the overlaod condition has with a duration of zero to indicate that the overlaod condition has
ended and use of the abatement algorithm is no longer needed. ended and use of the abatement algorithm is no longer needed.
The reacting node also determines when the overload report expires The reacting node also determines when the overload report expires
based on the OC-Validaty-Duration AVP in the overload report and based on the OC-Validaty-Duration AVP in the overload report and
stops applying the abatement algorithm when the report expires. stops applying the abatement algorithm when the report expires.
3.4. DOIC Extensibility (Non normative) 3.4. DOIC Extensibility
The DOIC solutions is designed to be extensible. This extensibility The DOIC solutions is designed to be extensible. This extensibility
is based on existing Diameter based extensibility mechanisms. is based on existing Diameter based extensibility mechanisms.
There are multiple categories of extensions that are expected. This There are multiple categories of extensions that are expected. This
includes the definition of new overload abatement algorithms, the includes the definition of new overload abatement algorithms, the
definition of new report types and new definitions of the scope of definition of new report types and new definitions of the scope of
messages impacted by an overload report. messages impacted by an overload report.
The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes
skipping to change at page 10, line 43 skipping to change at page 10, line 43
Overload abatement algorithms use the OC-OLR AVP to communicate Overload abatement algorithms use the OC-OLR AVP to communicate
overload occurances. This AVP can also be extended to add new AVPs overload occurances. This AVP can also be extended to add new AVPs
allowing a reporting nodes to communicate additional information allowing a reporting nodes to communicate additional information
about handling an overload condition. about handling an overload condition.
If necessary, new extensions can also define new top level AVPs. It If necessary, new extensions can also define new top level AVPs. It
is, however, recommended that DOIC extensions use the OC-Supported- is, however, recommended that DOIC extensions use the OC-Supported-
Features and OC-OLR to carry all DOIC related AVPs. Features and OC-OLR to carry all DOIC related AVPs.
3.5. Simplified Example Architecture (Non normative) 3.5. Simplified Example Architecture
Figure 1 illustrates the simplified architecture for Diameter Figure 1 illustrates the simplified architecture for Diameter
overload information conveyance. overload information conveyance.
Realm X Same or other Realms Realm X Same or other Realms
<--------------------------------------> <----------------------> <--------------------------------------> <---------------------->
+--^-----+ : (optional) : +--^-----+ : (optional) :
|Diameter| : : |Diameter| : :
|Server A|--+ .--. : +---^----+ : .--. |Server A|--+ .--. : +---^----+ : .--.
skipping to change at page 11, line 35 skipping to change at page 11, line 35
Figure 1: Simplified architecture choices for overload indication Figure 1: Simplified architecture choices for overload indication
delivery delivery
In Figure 1, the Diameter overload indication can be conveyed (1) In Figure 1, the Diameter overload indication can be conveyed (1)
end-to-end between servers and clients or (2) between servers and end-to-end between servers and clients or (2) between servers and
Diameter agent inside the realm and then between the Diameter agent Diameter agent inside the realm and then between the Diameter agent
and the clients when the Diameter agent acting as back-to-back-agent and the clients when the Diameter agent acting as back-to-back-agent
for DOIC purposes. for DOIC purposes.
3.6. Considerations for Applications Integrating the DOIC Solution (Non 3.6. Considerations for Applications Integrating the DOIC Solution
normative)
THis section outlines considerations to be taken into account when THis section outlines considerations to be taken into account when
integrating the DOIC solution into Diameter applications. integrating the DOIC solution into Diameter applications.
3.6.1. Application Classification (Non normative) 3.6.1. Application Classification
The following is a classification of Diameter applications and The following is a classification of Diameter applications and
requests. This discussion is meant to document factors that play requests. This discussion is meant to document factors that play
into decisions made by the Diameter identity responsible for handling into decisions made by the Diameter identity responsible for handling
overload reports. overload reports.
Section 8.1 of [RFC6733] defines two state machines that imply two Section 8.1 of [RFC6733] defines two state machines that imply two
types of applications, session-less and session-based applications. types of applications, session-less and session-based applications.
The primary difference between these types of applications is the The primary difference between these types of applications is the
skipping to change at page 12, line 41 skipping to change at page 12, line 41
but use other session-related information in the Diameter requests but use other session-related information in the Diameter requests
for this purpose. The 3GPP defined Cx application [Cx] is an for this purpose. The 3GPP defined Cx application [Cx] is an
example of a pseudo-session application. example of a pseudo-session application.
The Credit-Control application defined in [RFC4006] is an example of The Credit-Control application defined in [RFC4006] is an example of
a Diameter session-based application. a Diameter session-based application.
The handling of overload reports must take the type of application The handling of overload reports must take the type of application
into consideration, as discussed in Section 3.6.2. into consideration, as discussed in Section 3.6.2.
3.6.2. Application Type Overload Implications (Non normative) 3.6.2. Application Type Overload Implications
This section discusses considerations for mitigating overload This section discusses considerations for mitigating overload
reported by a Diameter entity. This discussion focuses on the type reported by a Diameter entity. This discussion focuses on the type
of application. Section 3.6.3 discusses considerations for handling of application. Section 3.6.3 discusses considerations for handling
various request types when the target server is known to be in an various request types when the target server is known to be in an
overloaded state. overloaded state.
These discussions assume that the strategy for mitigating the These discussions assume that the strategy for mitigating the
reported overload is to reduce the overall workload sent to the reported overload is to reduce the overall workload sent to the
overloaded entity. The concept of applying overload treatment to overloaded entity. The concept of applying overload treatment to
skipping to change at page 14, line 5 skipping to change at page 14, line 5
towards an overloaded Diameter entity for a session-based towards an overloaded Diameter entity for a session-based
application might tend to reject new session requests prior to application might tend to reject new session requests prior to
rejecting intra-session requests. In addition, session ending rejecting intra-session requests. In addition, session ending
requests might be given a lower probability of being rejected as requests might be given a lower probability of being rejected as
rejecting session ending requests could result in session status rejecting session ending requests could result in session status
being out of sync between the Diameter clients and servers. being out of sync between the Diameter clients and servers.
Application designers that would decide to reject mid-session Application designers that would decide to reject mid-session
requests will need to consider whether the rejection invalidates requests will need to consider whether the rejection invalidates
the session and any resulting session clean-up procedures. the session and any resulting session clean-up procedures.
3.6.3. Request Transaction Classification (Non normative) 3.6.3. Request Transaction Classification
Independent Request: Independent Request:
An independent request is not correlated to any other requests An independent request is not correlated to any other requests
and, as such, the lifetime of the session-id is constrained to an and, as such, the lifetime of the session-id is constrained to an
individual transaction. individual transaction.
Session-Initiating Request: Session-Initiating Request:
A session-initiating request is the initial message that A session-initiating request is the initial message that
skipping to change at page 14, line 45 skipping to change at page 14, line 45
Pseudo-Session Requests: Pseudo-Session Requests:
Pseudo-session requests are independent requests and do not use Pseudo-session requests are independent requests and do not use
the same Session-Id but are correlated by other session-related the same Session-Id but are correlated by other session-related
information contained in the request. There exists Diameter information contained in the request. There exists Diameter
applications that define an expected ordering of transactions. applications that define an expected ordering of transactions.
This sequencing of independent transactions results in a pseudo This sequencing of independent transactions results in a pseudo
session. The AIR, MAR and SAR requests in the 3GPP defined Cx session. The AIR, MAR and SAR requests in the 3GPP defined Cx
[Cx] application are examples of pseudo-session requests. [Cx] application are examples of pseudo-session requests.
3.6.4. Request Type Overload Implications (Non normative) 3.6.4. Request Type Overload Implications
The request classes identified in Section 3.6.3 have implications on The request classes identified in Section 3.6.3 have implications on
decisions about which requests should be throttled first. The decisions about which requests should be throttled first. The
following list of request treatment regarding throttling is provided following list of request treatment regarding throttling is provided
as guidelines for application designers when implementing the as guidelines for application designers when implementing the
Diameter overload control mechanism described in this document. The Diameter overload control mechanism described in this document. The
exact behavior regarding throttling is a matter of local policy, exact behavior regarding throttling is a matter of local policy,
unless specifically defined for the application. unless specifically defined for the application.
Independent requests: Independent requests:
skipping to change at page 16, line 7 skipping to change at page 16, line 7
and server to maintain the ongoing session state. Session and server to maintain the ongoing session state. Session
terminating requests should be throttled less aggressively in terminating requests should be throttled less aggressively in
order to gracefully terminate sessions, allow clean-up of the order to gracefully terminate sessions, allow clean-up of the
related resources (e.g. session state) and get rid of the need for related resources (e.g. session state) and get rid of the need for
other intra-session requests, reducing the session management other intra-session requests, reducing the session management
impact on the overloaded entity. The default handling of other impact on the overloaded entity. The default handling of other
intra-session requests might be to treat them equally when making intra-session requests might be to treat them equally when making
throttling decisions. There might also be application level throttling decisions. There might also be application level
considerations whether some request types are favored over others. considerations whether some request types are favored over others.
4. Solution Procedures (Normative) 4. Solution Procedures
This section outlines the normative behavior associated with the DOIC This section outlines the normative behavior associated with the DOIC
solution. solution.
4.1. Capability Announcement (Normative) 4.1. Capability Announcement
This section defines DOIC Capability Announcement (DCA) behavior. This section defines DOIC Capability Announcement (DCA) behavior.
The DCA procedures are used to indicate support for DOIC and support The DCA procedures are used to indicate support for DOIC and support
for DOIC features. The DOIC features include overload abatement for DOIC features. The DOIC features include overload abatement
algorithms supported. It might also include new report types or algorithms supported. It might also include new report types or
other extensions documented in the future. other extensions documented in the future.
Diameter nodes indicate support for DOIC by including the OC- Diameter nodes indicate support for DOIC by including the OC-
Supported-Features AVP in messages sent or handled by the node. Supported-Features AVP in messages sent or handled by the node.
Diameter agents that support DOIC MUST ensure that all messages have Diameter agents that support DOIC MUST ensure that all messages have
the OC-Supporting-Features AVP. If a message handled by the DOIC the OC-Supporting-Features AVP. If a message handled by the DOIC
agent does not include the OC-Supported-Features AVP then the DOIC agent does not include the OC-Supported-Features AVP then the DOIC
agent inserts the AVP. If the message already has the AVP then the agent inserts the AVP. If the message already has the AVP then the
agent either leaves it unchanged in the relayed message or modifies agent either leaves it unchanged in the relayed message or modifies
it to reflect a mixed set of DOIC features. it to reflect a mixed set of DOIC features.
4.1.1. Reacting Node Behavior (Normative) 4.1.1. Reacting Node Behavior
A reacting node MUST include the OC-Supported-Features AVP in all A reacting node MUST include the OC-Supported-Features AVP in all
request messages. request messages.
A reacting node MUST include the OC-Feature-Vector AVP with an A reacting node MUST include the OC-Feature-Vector AVP with an
indication of the loss algorithm. indication of the loss algorithm.
A reacting node SHOULD indicate support for all other DOIC features A reacting node SHOULD indicate support for all other DOIC features
it supports. it supports.
An OC-Supported-Features AVP in answer messages indicates there is a An OC-Supported-Features AVP in answer messages indicates there is a
reporting node for the transaction. The reacting node MAY take reporting node for the transaction. The reacting node MAY take
action based on the features indicated in the OC-Feature-Vector AVP. action based on the features indicated in the OC-Feature-Vector AVP.
Note that the loss abatement algorithm is the only feature Note that the loss abatement algorithm is the only feature
described in this document and it does not require action to be described in this document and it does not require action to be
taken by the reacting node except when the answer message also has taken by the reacting node except when the answer message also has
an overload report. This behavior is described in Section 4.2 and an overload report. This behavior is described in Section 4.2 and
Section 5. Section 5.
4.1.2. Reporting Node Behavior (Normative) 4.1.2. Reporting Node Behavior
Upon receipt of a request message, a reporting node determines if Upon receipt of a request message, a reporting node determines if
there is a reacting node for the transaction based on the presence of there is a reacting node for the transaction based on the presence of
the OC-Supported-Features AVP. the OC-Supported-Features AVP.
Based on the content of the OC-Supported-Features AVP in the request Based on the content of the OC-Supported-Features AVP in the request
message, the reporting node knows what overload control functionality message, the reporting node knows what overload control functionality
supported by reacting node(s). The reporting node then acts supported by reacting node(s). The reporting node then acts
accordingly for the subsequent answer messages it initiates. accordingly for the subsequent answer messages it initiates.
skipping to change at page 18, line 5 skipping to change at page 18, line 5
The reporting node MUST NOT include the OC-Supported-Features AVP, The reporting node MUST NOT include the OC-Supported-Features AVP,
OC-OLR AVP or any other overload control AVPs defined in extension OC-OLR AVP or any other overload control AVPs defined in extension
drafts in response messages for transactions where the request drafts in response messages for transactions where the request
message does not include the OC-Supported-Features AVP. Lack of the message does not include the OC-Supported-Features AVP. Lack of the
OC-Supported-Features AVP in the request message indicates that there OC-Supported-Features AVP in the request message indicates that there
is no reacting node for the transaction. is no reacting node for the transaction.
An agent MAY modify the OC-Supported-Features AVP carried in answer An agent MAY modify the OC-Supported-Features AVP carried in answer
messages. messages.
4.1.3. Agent Behavior (Normative) 4.1.3. Agent Behavior
Editor's note -- Need to add this section. Editor's note -- Need to add this section.
4.2. Overload Report Processing (Normative) 4.2. Overload Report Processing
4.2.1. Overload Control State (Normative) 4.2.1. Overload Control State
Both reacting and reporting nodes maintain an overload control state Both reacting and reporting nodes maintain an overload control state
(OCS) for active overload reports. (OCS) for active overload reports.
4.2.1.1. Overload Control State for Reacting Nodes 4.2.1.1. Overload Control State for Reacting Nodes
A reacting node maintains the following OCS per supported Diameter A reacting node maintains the following OCS per supported Diameter
application: application:
o A host-type Overload Control State for each Destination-Host o A host-type Overload Control State for each Destination-Host
skipping to change at page 20, line 25 skipping to change at page 20, line 25
Reporting nodes delete an OCS when it expires. Reporting nodes delete an OCS when it expires.
Editor's note: Reporting nodes should send updated overload reports Editor's note: Reporting nodes should send updated overload reports
with a validity duration of zero for a period of time after an OCS with a validity duration of zero for a period of time after an OCS
expires or is removed due to the overload condition ending. expires or is removed due to the overload condition ending.
Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg)
when they detect the need to modify the requested amount of when they detect the need to modify the requested amount of
application app-id traffic reduction. application app-id traffic reduction.
4.2.2. Reacting Node Behavior (Normative) 4.2.2. Reacting Node Behavior
Once a reacting node receives an OC-OLR AVP from a reporting node, it Once a reacting node receives an OC-OLR AVP from a reporting node, it
applies traffic abatement based on the selected algorithm with the applies traffic abatement based on the selected algorithm with the
reporting node and the current overload condition. The reacting node reporting node and the current overload condition. The reacting node
learns the reporting node supported abatement algorithms directly learns the reporting node supported abatement algorithms directly
from the received answer message containing the OC-Supported-Features from the received answer message containing the OC-Supported-Features
AVP. AVP.
The received OC-Supported-Features AVP does not change the existing The received OC-Supported-Features AVP does not change the existing
overload condition and/or traffic abatement algorithm settings if the overload condition and/or traffic abatement algorithm settings if the
skipping to change at page 22, line 12 skipping to change at page 22, line 12
updated overload report indicates that the overload condition has updated overload report indicates that the overload condition has
ended and that the overload state is no longer valid. ended and that the overload state is no longer valid.
In the case that the validity duration expires or is explicitly In the case that the validity duration expires or is explicitly
signaled as being no longer valid the state associated with the signaled as being no longer valid the state associated with the
overload report MUST be removed and any abatement associated with the overload report MUST be removed and any abatement associated with the
overload report MUST be ended in a controlled fashion. After overload report MUST be ended in a controlled fashion. After
removing the overload state the sequence number MUST NOT be used for removing the overload state the sequence number MUST NOT be used for
future comparisons of sequence numbers. future comparisons of sequence numbers.
4.2.3. Reporting Node Behavior (Normative) 4.2.3. Reporting Node Behavior
A reporting node is a Diameter node inserting an OC-OLR AVP in a A reporting node is a Diameter node inserting an OC-OLR AVP in a
Diameter message in order to inform a reacting node about an overload Diameter message in order to inform a reacting node about an overload
condition and request Diameter traffic abatement. condition and request Diameter traffic abatement.
The operation on the reporting node is straight forward. The The operation on the reporting node is straight forward. The
reporting node learns the capabilities of the reacting node when it reporting node learns the capabilities of the reacting node when it
receives the OC-Supported-Features AVP as part of any Diameter receives the OC-Supported-Features AVP as part of any Diameter
request message. If the reporting node shares at least one common request message. If the reporting node shares at least one common
feature with the reacting node, then the DOIC can be enabled between feature with the reacting node, then the DOIC can be enabled between
skipping to change at page 22, line 45 skipping to change at page 22, line 45
A reporting node MAY rely on the OC-Validity-Duration AVP values for A reporting node MAY rely on the OC-Validity-Duration AVP values for
the implicit overload control state cleanup on the reacting node. the implicit overload control state cleanup on the reacting node.
However, it is RECOMMENDED that the reporting node always explicitly However, it is RECOMMENDED that the reporting node always explicitly
indicates the end of a overload condition. indicates the end of a overload condition.
The reporting node SHOULD indicate the end of an overload occurrence The reporting node SHOULD indicate the end of an overload occurrence
by sending a new OLR with OC-Validity-Duration set to a value of zero by sending a new OLR with OC-Validity-Duration set to a value of zero
("0"). The reporting node SHOULD insure that all reacting nodes ("0"). The reporting node SHOULD insure that all reacting nodes
receive the updated overload report. receive the updated overload report.
4.2.4. Agent Behavior (Normative) 4.2.4. Agent Behavior
Editor's note -- Need to add this section. Editor's note -- Need to add this section.
4.3. Protocol Extensibility (Normative) 4.3. Protocol Extensibility
The overload control solution can be extended, e.g. with new traffic The overload control solution can be extended, e.g. with new traffic
abatement algorithms, new report types or other new functionality. abatement algorithms, new report types or other new functionality.
When defining a new extension a new feature bit MUST be defined for When defining a new extension a new feature bit MUST be defined for
the OC-Feature-Vector. This feature bit is used to communicate the OC-Feature-Vector. This feature bit is used to communicate
support for the new feature. support for the new feature.
The extention may also define new AVPs for use in DOIC Capability The extention may also define new AVPs for use in DOIC Capability
Anouncement and for use in DOIC Overload reporting. These new AVP Anouncement and for use in DOIC Overload reporting. These new AVP
skipping to change at page 24, line 5 skipping to change at page 24, line 5
backward compatibility for the given OC-Report-Type AVP value implied backward compatibility for the given OC-Report-Type AVP value implied
report handling semantics. If the new sub-AVPs imply new semantics report handling semantics. If the new sub-AVPs imply new semantics
for handling the indicated report type, then a new OC-Report-Type AVP for handling the indicated report type, then a new OC-Report-Type AVP
value MUST be defined. value MUST be defined.
New features (feature bits in the OC-Feature-Vector AVP) and report New features (feature bits in the OC-Feature-Vector AVP) and report
types (in the OC-Report-Type AVP) MUST be registered with IANA. As types (in the OC-Report-Type AVP) MUST be registered with IANA. As
with any Diameter specification, new AVPs MUST also be registered with any Diameter specification, new AVPs MUST also be registered
with IANA. See Section 8 for the required procedures. with IANA. See Section 8 for the required procedures.
5. Loss Algorithm (Normative) 5. Loss Algorithm
This section documents the Diameter overload loss abatement This section documents the Diameter overload loss abatement
algorithm. algorithm.
5.1. Overview (Non normative) 5.1. Overview
The DOIC specification supports the ability for multiple overload The DOIC specification supports the ability for multiple overload
abatement algorithms to be specified. The abatement algorithm used abatement algorithms to be specified. The abatement algorithm used
for any instance of overload is determined by the Diameter Overload for any instance of overload is determined by the Diameter Overload
Capability Announcement process documented in Section 4.1. Capability Announcement process documented in Section 4.1.
The loss algorithm described in this section is the default algorithm The loss algorithm described in this section is the default algorithm
that must be supported by all Diameter nodes that support DOIC. that must be supported by all Diameter nodes that support DOIC.
The loss algorithm is designed to be a straightforward and stateless The loss algorithm is designed to be a straightforward and stateless
skipping to change at page 25, line 14 skipping to change at page 25, line 14
5.2. Use of OC-Reduction-Percentage AVP 5.2. Use of OC-Reduction-Percentage AVP
A reporting node using the loss algorithm must use the OC-Reduction- A reporting node using the loss algorithm must use the OC-Reduction-
Percentage AVP (Section 6.7 to indicated the desired percentage of Percentage AVP (Section 6.7 to indicated the desired percentage of
traffic reduction.) traffic reduction.)
Editor's note: The above duplicates what is in the OC-Reduction- Editor's note: The above duplicates what is in the OC-Reduction-
Percentage AVP section can probably be removed. Percentage AVP section can probably be removed.
5.3. Reporting Node Behavior (Normative) 5.3. Reporting Node Behavior
The method a reporting nodes uses to determine the amount of traffic The method a reporting nodes uses to determine the amount of traffic
reduction required to address an overload condition is an reduction required to address an overload condition is an
implementation decision. implementation decision.
When a reporting node that has selected the loss abatement algorithm When a reporting node that has selected the loss abatement algorithm
determines the need to request a traffic reduction it must include an determines the need to request a traffic reduction it must include an
OC-OLR AVP in all response messages. OC-OLR AVP in all response messages.
The reporting node must indicate a percentage reduction in the OC- The reporting node must indicate a percentage reduction in the OC-
skipping to change at page 25, line 36 skipping to change at page 25, line 36
The reporting node may change the reduction percentage in subsequent The reporting node may change the reduction percentage in subsequent
overload reports. When doing so the reporting node must conform to overload reports. When doing so the reporting node must conform to
overload report handing specified in Section 4.2.3. overload report handing specified in Section 4.2.3.
When the reporting node determines it no longer needs a reduction in When the reporting node determines it no longer needs a reduction in
traffic the reporting node should send an overload report indicating traffic the reporting node should send an overload report indicating
the overload report is no longer valid, as specified in the overload report is no longer valid, as specified in
Section 4.2.3. Section 4.2.3.
5.4. Reacting Node Behavior (Normative) 5.4. Reacting Node Behavior
The method a reacting node uses to determine which request messages The method a reacting node uses to determine which request messages
are given abatement treatment is an implementation decision. are given abatement treatment is an implementation decision.
When receiving an OC-OLR in an answer message where the algorithm When receiving an OC-OLR in an answer message where the algorithm
indicated in the OC-Supported-Features AVP is the loss algorithm, the indicated in the OC-Supported-Features AVP is the loss algorithm, the
reacting node must attempt to apply abatement treatment to the reacting node must attempt to apply abatement treatment to the
requested percentage of request messages sent. requested percentage of request messages sent.
Note: the loss algorithm is a stateless algorithm. As a result, Note: the loss algorithm is a stateless algorithm. As a result,
skipping to change at page 26, line 32 skipping to change at page 26, line 32
It is suggested that the reacting node decrease the amount of traffic It is suggested that the reacting node decrease the amount of traffic
given abatement treatment by 20% each second until the reduction is given abatement treatment by 20% each second until the reduction is
completely removed and no traffic is given abatement treatment. completely removed and no traffic is given abatement treatment.
The goal of this behavior is to reduce the probability of overload The goal of this behavior is to reduce the probability of overload
condition thrashing where an immediate transition from 100% condition thrashing where an immediate transition from 100%
reduction to 0% reduction results in the reporting node moving reduction to 0% reduction results in the reporting node moving
quickly back into an overload condition. quickly back into an overload condition.
6. Attribute Value Pairs (Normative) 6. Attribute Value Pairs
This section describes the encoding and semantics of the Diameter This section describes the encoding and semantics of the Diameter
Overload Indication Attribute Value Pairs (AVPs) defined in this Overload Indication Attribute Value Pairs (AVPs) defined in this
document. document.
When added to existing commands, both OC-Feature-Vector and OC-OLR When added to existing commands, both OC-Feature-Vector and OC-OLR
AVPs SHOULD have the M-bit flag cleared to avoid backward AVPs SHOULD have the M-bit flag cleared to avoid backward
compatibility issues. compatibility issues.
A new application specification can incorporate the overload control A new application specification can incorporate the overload control
skipping to change at page 41, line 47 skipping to change at page 41, line 47
likely different than that for either S1 or S2. The agent likely different than that for either S1 or S2. The agent
forward's S2's report back to the client in the Diameter answer. forward's S2's report back to the client in the Diameter answer.
Additionally, the agent generates a new report for the realm of Additionally, the agent generates a new report for the realm of
"realm", and inserts that report into the answer. The client "realm", and inserts that report into the answer. The client
throttles requests with Destination-Host:S1 at one rate, requests throttles requests with Destination-Host:S1 at one rate, requests
with Destination-Host:S2 at another rate, and requests with no with Destination-Host:S2 at another rate, and requests with no
Destination-Host AVP at yet a third rate. (Since S3 has not Destination-Host AVP at yet a third rate. (Since S3 has not
indicated overload, the client does not throttle requests with indicated overload, the client does not throttle requests with
Destination-Host:S3.) Destination-Host:S3.)
Appendix C. Restructuring of -02 version of the draft
This section captures the initial plan for restructuring the DOIC
specification from the -02 version to the new -03 version.
1. Introduction (non normative)
-- Existing Text from section 1. --
2. Terminology and Abbreviations (non normative)
-- Existing Text from section 2. --
3. Solution Overview (Non normative)
-- Existing text from section 3. --
3.1 Overload Control Endpoints (Non normative)
-- New text leveraging text from existing section 5.1 --
3.2 Piggybacking Principle (Non normative)
-- Existing text from existing section 5.2, with enhancements --
3.3 DOIC Capability Discovery (Non normative)
-- New text leveraging text from existing section 5.3 --
3.4 DOIC Overload Condition Reporting (Non normative)
-- New text --
3.5 DOIC Extensibility (Non normative)
-- New text leveraging text from existing Section 5.4 --
3.5 Simplified Example Architecture (Non normative)
-- Existing text from section 3.1.6, with enhancements --
3.6 Considerations for Applications Integrating the DOIC Solution (Non normative)
-- New text --
3.6.1. Application Classification (Non normative)
-- Existing text from section 3.1.1 --
3.6.2. Application Type Overload Implications (Non normative)
-- Existing text from section 3.1.2 --
3.6.3. Request Transaction Classification (Non normative)
-- Existing text from section 3.1.3 --
3.6.4. Request Type Overload Implications (Non normative)
-- Existing text from section 3.1.4 --
4. Solution Procedures (Normative)
4.1 Capability Announcement (Normative)
-- Existing text from section 5.3 --
4.1.1. Reacting Node Behavior (Normative)
-- Existing text from section 5.3.1 --
4.1.2. Reporting Node Behavior (Normative)
-- Existing text from section 5.3.2 --
4.1.3. Agent Behavior (Normative)
-- Existing text from section 5.3.3 --
4.2. Overload Report Processing (Normative)
4.2.1. Overload Control State (Normative)
-- Existing text from section 5.5.1 --
4.2.2. Reacting Node Behavior (Normative)
-- Existing text from section 5.5.2 --
4.2.3. Reporting Node Behavior (Normative)
-- Existing text from section 5.5.3 --
4.2.4. Agent Behavior (Normative)
-- Existing text from section 5.5.4 --
4.3. Protocol Extensibility (Normative)
-- Existing text from section 5.4 --
5. Loss Algorithm (Normative)
-- New text pulling from information spread through the document --
5.1. Overview (Non normative)
-- New text pulling from information spread through the document --
5.2. Reporting Node Behavior (Normative)
-- New text pulling from information spread through the document --
5.3. Reacting Node Behavior (Normative)
-- New text pulling from information spread through the document --
6. Attribute Value Pairs (Normative)
-- Existing text from section 4. --
6.1. OC-Supported-Features AVP
-- Existing text from section 4.1 --
6.2. OC-Feature-Vector AVP
-- Existing text from section 4.2 --
6.3. OC-OLR AVP
-- Existing text from section 4.3 --
6.4. OC-Sequence-Number AVP
-- Existing text from section 4.4 --
6.5. OC-Validity-Duration AVP
-- Existing text from section 4.5 --
6.6. OC-Report-Type AVP
-- Existing text from section 4.6 --
6.7. OC-Reduction-Percentage AVP
-- Existing text from section 4.7 --
6.8. Attribute Value Pair flag rules
-- Existing text from section 4.8 --
7. Error Response Codes
-- New text based on resolution of issue --
8. IANA Considerations
-- Existing text from section 7. --
8.1. AVP codes
-- Existing text from section 7.1 --
8.2. New registries
-- Existing text from section 7.2 --
9. Security Considerations
-- Existing text from section 8. --
9.1. Potential Threat Modes
-- Existing text from section 8.1 --
9.2. Denial of Service Attacks
-- Existing text from section 8.2 --
9.3. Non-Compliant Nodes
-- Existing text from section 8.3 --
9.4. End-to End-Security Issues
-- Existing text from section 8.4 --
10. Contributors
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Issues left for future specifications
A.1. Additional traffic abatement algorithms
A.2. Agent Overload
A.3. DIAMETER_TOO_BUSY clarifications
A.4. Per reacting node reports
Appendix B. Examples
B.1. Mix of Destination-Realm routed requests and Destination-
Host routed requests
Authors' Addresses Authors' Addresses
Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
Broadcom Broadcom
Porkkalankatu 24 Porkkalankatu 24
Helsinki FIN-00180 Helsinki FIN-00180
Finland Finland
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
Steve Donovan (editor) Steve Donovan (editor)
Oracle Oracle
 End of changes. 36 change blocks. 
172 lines changed or deleted 57 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------000004040007010809070201-- From nobody Mon Oct 20 01:23:44 2014 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 C063D1A6FD1 for ; Mon, 20 Oct 2014 01:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 heoTMXdzZa9R for ; Mon, 20 Oct 2014 01:23:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 236441A6F39 for ; Mon, 20 Oct 2014 01:23:40 -0700 (PDT) Received: from localhost ([::1]:34495 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xg8Fc-00012W-Ax; Mon, 20 Oct 2014 01:23:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 08:23:36 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/68#comment:1 Message-ID: <090.f6378f7f9a4debc63e4a189576802cf2@trac.tools.ietf.org> References: <075.8d19bd9550e16275f187acd9d2a6195d@trac.tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <075.8d19bd9550e16275f187acd9d2a6195d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sui8sk0MgYV-Q5pcZUCFTbzU0I8 Cc: dime@ietf.org Subject: Re: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common abatemen algorithm X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 08:23:41 -0000 #68: Loss as the common abatemen algorithm Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Consensus reached to change the wording to the following: " Since the "loss" abatement algorithm [crossref] is mandatory to implement, DOIC can always be enabled between these two endpoints.†Changed in both sections mentioned above with expectation that the AVP description will be updated to pull out behavior definitions. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 01:48:51 2014 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 442C31A6FF0 for ; Mon, 20 Oct 2014 01:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YbiqMSM3ZU4d for ; Mon, 20 Oct 2014 01:48:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 16B331A6FEF for ; Mon, 20 Oct 2014 01:48:48 -0700 (PDT) Received: from localhost ([::1]:35480 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xg8dx-0000eV-Ab; Mon, 20 Oct 2014 01:48:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 08:48:45 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/71#comment:1 Message-ID: <090.9ebd4d96e50723be516d374d27c082b4@trac.tools.ietf.org> References: <075.42ce9b1c1c8c40b23a5717c66ad4bd65@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <075.42ce9b1c1c8c40b23a5717c66ad4bd65@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/RMFjrz0F4so_HFlAy9WDhxfGwlU Cc: dime@ietf.org Subject: Re: [Dime] [dime] #71 (draft-ietf-dime-ovli): Active overload report even if OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 08:48:50 -0000 #71: Active overload report even if OC-OLR is not received Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Updated with the above suggested wording. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 01:52:54 2014 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 0BDB61A6FF5 for ; Mon, 20 Oct 2014 01:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 iaghmNF0v0Qz for ; Mon, 20 Oct 2014 01:52:52 -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 57BD21A6FE7 for ; Mon, 20 Oct 2014 01:52:52 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:50475 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xg8hv-0005rw-2H for dime@ietf.org; Mon, 20 Oct 2014 01:52:51 -0700 Message-ID: <5444CD61.9040503@usdonovans.com> Date: Mon, 20 Oct 2014 10:52:49 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BPJFkru-VDF2NTSLw6jmM0CDYi4 Subject: [Dime] Resolution to #71 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, 20 Oct 2014 08:52:53 -0000 I've updated github with the change to #71. I did not manage to capture a diff on this one. Steve From nobody Mon Oct 20 01:58:12 2014 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 08FC51A6FF1 for ; Mon, 20 Oct 2014 01:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 d4O3W_pIosnN for ; Mon, 20 Oct 2014 01:58:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 DE5141A6FCB for ; Mon, 20 Oct 2014 01:58:08 -0700 (PDT) Received: from localhost ([::1]:35842 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xg8n0-00043S-6m; Mon, 20 Oct 2014 01:58:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 08:58:06 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/76#comment:1 Message-ID: <081.f73c7c0dfe1e15270f06c52e2c24715e@trac.tools.ietf.org> References: <066.4f1da7960fc11058290d816d3513056d@trac.tools.ietf.org> X-Trac-Ticket-ID: 76 In-Reply-To: <066.4f1da7960fc11058290d816d3513056d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/UElUDjVgrU-9Z5SWe6iPk9Llgqc Cc: dime@ietf.org Subject: Re: [Dime] [dime] #76 (draft-ietf-dime-ovli): Add report type ot OCS at reporting node X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 08:58:10 -0000 #76: Add report type ot OCS at reporting node Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Updated as suggested above. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 01:59:46 2014 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 420B91A6FCB for ; Mon, 20 Oct 2014 01:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3As6rxY1IcBc for ; Mon, 20 Oct 2014 01:59:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 127FB1A6FFC for ; Mon, 20 Oct 2014 01:59:44 -0700 (PDT) Received: from localhost ([::1]:35893 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xg8oW-0004BC-Qm; Mon, 20 Oct 2014 01:59:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 08:59:40 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/78#comment:1 Message-ID: <081.3e0b117748f2ac826541af6aaddd2c9f@trac.tools.ietf.org> References: <066.7563cf099a48a0e6ca19394c0b608cbd@trac.tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <066.7563cf099a48a0e6ca19394c0b608cbd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/yy9XViNmRbkXxKh3lZnWpDdTtJc Cc: dime@ietf.org Subject: Re: [Dime] [dime] #78 (draft-ietf-dime-ovli): Remove section 5.2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 08:59:45 -0000 #78: Remove section 5.2 Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Removed section 5.2 as suggested above. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 02:01:51 2014 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 261781A7006 for ; Mon, 20 Oct 2014 02:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CS8-Y3fIrglH for ; Mon, 20 Oct 2014 02:01:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 1F6351A7002 for ; Mon, 20 Oct 2014 02:01:49 -0700 (PDT) Received: from localhost ([::1]:36006 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xg8qY-0004oG-NK; Mon, 20 Oct 2014 02:01:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 09:01:46 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/79#comment:1 Message-ID: <081.1d2a377c7503993893beb0e6473d2334@trac.tools.ietf.org> References: <066.baf6a379d5a23d4c1fc75604089389cd@trac.tools.ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <066.baf6a379d5a23d4c1fc75604089389cd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/JrtRmKVWjSP9y3BmZQ4JwLv4R5w Cc: dime@ietf.org Subject: Re: [Dime] [dime] #79 (draft-ietf-dime-ovli): Section 5.4 - remove editor's note X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 09:01:50 -0000 #79: Section 5.4 - remove editor's note Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Removed editor's note as suggested above. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 02:03:36 2014 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 A1B151A7008 for ; Mon, 20 Oct 2014 02:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Sk2CTttZlOnN for ; Mon, 20 Oct 2014 02:03:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 72D791A7003 for ; Mon, 20 Oct 2014 02:03:31 -0700 (PDT) Received: from localhost ([::1]:36096 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xg8sC-0005F4-Qt; Mon, 20 Oct 2014 02:03:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 09:03:28 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/81#comment:1 Message-ID: <081.fac57d2cd2056a64f752ffa238a3f92b@trac.tools.ietf.org> References: <066.50e52056ddaf429706618e24a3ab2a3e@trac.tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <066.50e52056ddaf429706618e24a3ab2a3e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/g5dqU1wd8bPk-jHl_gri8wp1KJE Cc: dime@ietf.org Subject: Re: [Dime] [dime] #81 (draft-ietf-dime-ovli): 6.3. OC-OLR AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 09:03:35 -0000 #81: 6.3. OC-OLR AVP Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Agreed to leave the wording as is but to remove the editor's note. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 02:04:47 2014 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 EB2081A700A for ; Mon, 20 Oct 2014 02:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 K_ZtxmMl99Dr for ; Mon, 20 Oct 2014 02:04:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 816FE1A7003 for ; Mon, 20 Oct 2014 02:04:44 -0700 (PDT) Received: from localhost ([::1]:36163 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xg8tN-0005Pn-Pz; Mon, 20 Oct 2014 02:04:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 09:04:41 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/84#comment:1 Message-ID: <081.417e1352704fb6e822a57790474b33fa@trac.tools.ietf.org> References: <066.28524b7f3851b1ca821a52ca53aabef6@trac.tools.ietf.org> X-Trac-Ticket-ID: 84 In-Reply-To: <066.28524b7f3851b1ca821a52ca53aabef6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8k7T-r3hQzKab3fKmi_t8xebi7o Cc: dime@ietf.org Subject: Re: [Dime] [dime] #84 (draft-ietf-dime-ovli): 6.6. OC-Report-Type AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 09:04:46 -0000 #84: 6.6. OC-Report-Type AVP Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Agreed to remove the wording on default value as this is a required AVP. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 02:25:04 2014 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 1BCD01A7013 for ; Mon, 20 Oct 2014 02:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Jw2iLSfjK4uT for ; Mon, 20 Oct 2014 02:25:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 9DC901A700C for ; Mon, 20 Oct 2014 02:25:00 -0700 (PDT) Received: from localhost ([::1]:37643 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xg9Cx-00057B-Q2; Mon, 20 Oct 2014 02:24:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 09:24:55 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/74#comment:1 Message-ID: <081.1378161712de4393ca7bf67e4f09af71@trac.tools.ietf.org> References: <066.528fadde671b27f69242e310aaface81@trac.tools.ietf.org> X-Trac-Ticket-ID: 74 In-Reply-To: <066.528fadde671b27f69242e310aaface81@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/x1AV0zqMzpcKDm_wbKsZn2ZNxLU Cc: dime@ietf.org Subject: Re: [Dime] [dime] #74 (draft-ietf-dime-ovli): Move section 3.7. Considerations for Applications Integrating the DOIC Solution to Appendix X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 09:25:02 -0000 #74: Move section 3.7. Considerations for Applications Integrating the DOIC Solution to Appendix Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: The title is mistaken, it should be section 3.6. Moved this section to an appendix. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: enhancement | Status: closed Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 02:39:53 2014 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 CE5E11A7020 for ; Mon, 20 Oct 2014 02:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 At7CyI1J1rmn for ; Mon, 20 Oct 2014 02:39:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 8BC6E1A009E for ; Mon, 20 Oct 2014 02:39:50 -0700 (PDT) Received: from localhost ([::1]:38153 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xg9RK-0004rQ-DA; Mon, 20 Oct 2014 02:39:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 09:39:46 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/70#comment:1 Message-ID: <090.7188ac2e015fd665b34e407bdf3fe943@trac.tools.ietf.org> References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Ut70FDyChWiHg2LcPWboNub5yIs Cc: dime@ietf.org Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 09:39:52 -0000 #70: Appendix B - Example Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Agreed to remove the examples section and references to it. Also agreed to add wording that a reporting node must only send report types that it knows the reacting node supports. This resulted in the following wording in section 4.2.3: A reporting node MUST only send overload reports of a type advertised as supported by the reacting node. Note that a reacting node advertises support for the host and realm report types by including the OC-Supported-Features AVP in the request. Support for other report types must be explicitly indicated by a new feature bit in the OC-Feature-Vector AVP. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 03:49:36 2014 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 9140A1A802C for ; Mon, 20 Oct 2014 03:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 nK3DJCTvSnlq for ; Mon, 20 Oct 2014 03:49:34 -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 77F571A8028 for ; Mon, 20 Oct 2014 03:49:34 -0700 (PDT) Received: from [64.31.33.196] (port=51256 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgAWp-0000v4-KK for dime@ietf.org; Mon, 20 Oct 2014 03:49:32 -0700 Message-ID: <5444E8B9.8090002@usdonovans.com> Date: Mon, 20 Oct 2014 12:49:29 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SxkDIL5G4soRfSPMcq3X7dR2aog Subject: [Dime] Proposal for error response wording (issue 85) 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, 20 Oct 2014 10:49:35 -0000 We came to the following agreements on error responses: - Servers rejecting a Diameter request due to an overload condition should send a 3002 DIAMETER_TOO_BUSY error response. - Agents rejecting a Diameter request due to an overload condition should send a 5012 DIAMETER_UNABLE_TO_COMPLY. I propose that we generalize this to the following: - Reporting nodes rejecting a Diameter request due to an overload condition SHOULD send a 3002 DIAMETER-TOO-BUSY error response. - Reacting nodes rejecting a Diameter request due to an overload condition SHOULD send a UNABLE-TO-COMPLY. This would mean that an agent acting as a reporting node (i.e.; server doesn't support DOIC or agent is acting as a server front end) would sent the TOO_BUSY response and an agent acting as a reacting node (i.e.; a client doesn't support DOIC) then it sends a UNABLE_TO_COMPLY response. I propose adding this to a new section 4.2.4. The existing 4.2.4 on agent behavior will be deleted. I will hold off making this change until tomorrow (Tuesday morning). Regards, Steve From nobody Mon Oct 20 04:12:06 2014 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 D6A901A8034 for ; Mon, 20 Oct 2014 04:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5DpMiXDLnVy9 for ; Mon, 20 Oct 2014 04:12:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 75B2C1A7035 for ; Mon, 20 Oct 2014 04:12:02 -0700 (PDT) Received: from localhost ([::1]:42490 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgAsX-0001dg-MV; Mon, 20 Oct 2014 04:11:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 11:11:57 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/72#comment:1 Message-ID: <090.79cda897b8f03e5e7b73357b5d1b2347@trac.tools.ietf.org> References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> X-Trac-Ticket-ID: 72 In-Reply-To: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9kQP45Q8bKq_mJF65KNWT3ubsAk Cc: dime@ietf.org Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 11:12:04 -0000 #72: Reporting Node Behaviour when OC-OLR is not received Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Added the following to section 4.2.3 per previous email discussions: A reporting node MAY choose to not send an overload report to a reacting node if it can guarantee that this overload report is already active in the reacting node. Note - In some cases (e.g. when there are one or multiple agents in the path between reporting and reacting nodes, or when overload reports are discarded by reacting nodes) the reporting node may not be able to guarantee that the reacting node has received the report. Also changed wording in the loss section reporting node behavior section to refer to section 4.2.3. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: enhancement | Status: closed Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 04:20:25 2014 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 079F61A6FE8 for ; Mon, 20 Oct 2014 01:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 hEcFvoMsikw0 for ; Mon, 20 Oct 2014 01:25:01 -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 5D7FE1A6FD1 for ; Mon, 20 Oct 2014 01:25:01 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:50384 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xg8Gx-0000HR-9A for dime@ietf.org; Mon, 20 Oct 2014 01:25:00 -0700 Message-ID: <5444C6D9.80102@usdonovans.com> Date: Mon, 20 Oct 2014 10:24:57 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------050606030204050906070403" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/K1_a3yL-PsBKulTwJ1anM9BmBlg X-Mailman-Approved-At: Mon, 20 Oct 2014 04:19:58 -0700 Subject: [Dime] Resolved issue 68 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, 20 Oct 2014 08:25:05 -0000 X-List-Received-Date: Mon, 20 Oct 2014 08:25:05 -0000 This is a multi-part message in MIME format. --------------050606030204050906070403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've updated -04 in github with the resolution to issue #68. The diff is attached. Regards, Steve --------------050606030204050906070403 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 2, line 48 skipping to change at page 2, line 48
4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 23 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 23
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 24 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2. Use of OC-Reduction-Percentage AVP . . . . . . . . . . . 25 5.2. Use of OC-Reduction-Percentage AVP . . . . . . . . . . . 25
5.3. Reporting Node Behavior . . . . . . . . . . . . . . . . . 25 5.3. Reporting Node Behavior . . . . . . . . . . . . . . . . . 25
5.4. Reacting Node Behavior . . . . . . . . . . . . . . . . . 25 5.4. Reacting Node Behavior . . . . . . . . . . . . . . . . . 25
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 26 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 26
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 27 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 27
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 27 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 27
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 28 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 28
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 29 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 28
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 29 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 29
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 30 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 29
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 31 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 31
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 31 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 31
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 32 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 32 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 32
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 33 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 32
9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 33 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 33
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 34 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 34
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 35 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 34
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 35 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 34
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 36 11.1. Normative References . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 37 11.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Issues left for future specifications . . . . . . . 37 Appendix A. Issues left for future specifications . . . . . . . 37
A.1. Additional traffic abatement algorithms . . . . . . . . . 37 A.1. Additional traffic abatement algorithms . . . . . . . . . 37
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 37 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 37
A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 38 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 37
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 38 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 37
B.1. Mix of Destination-Realm routed requests and Destination- B.1. Mix of Destination-Realm routed requests and Destination-
Host routed requests . . . . . . . . . . . . . . . . . . 38 Host routed requests . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This specification defines a base solution for Diameter Overload This specification defines a base solution for Diameter Overload
Control (DOC), refered to as Diameter Overload Indication Conveyance Control (DOC), refered to as Diameter Overload Indication Conveyance
(DOIC). The requirements for the solution are described and (DOIC). The requirements for the solution are described and
discussed in the corresponding design requirements document discussed in the corresponding design requirements document
[RFC7068]. Note that the overload control solution defined in this [RFC7068]. Note that the overload control solution defined in this
specification does not address all the requirements listed in specification does not address all the requirements listed in
skipping to change at page 22, line 21 skipping to change at page 22, line 21
4.2.3. Reporting Node Behavior 4.2.3. Reporting Node Behavior
A reporting node is a Diameter node inserting an OC-OLR AVP in a A reporting node is a Diameter node inserting an OC-OLR AVP in a
Diameter message in order to inform a reacting node about an overload Diameter message in order to inform a reacting node about an overload
condition and request Diameter traffic abatement. condition and request Diameter traffic abatement.
The operation on the reporting node is straight forward. The The operation on the reporting node is straight forward. The
reporting node learns the capabilities of the reacting node when it reporting node learns the capabilities of the reacting node when it
receives the OC-Supported-Features AVP as part of any Diameter receives the OC-Supported-Features AVP as part of any Diameter
request message. If the reporting node shares at least one common request message. Since the loss abatement algorithm Section 5 is
feature with the reacting node, then the DOIC can be enabled between mandatory to implement DOIC can always be enabled between these DOIC
these DOIC nodes See Section 4.1 for further discussion on the nodes See Section 4.1 for further discussion on the capability and
capability and feature announcement. feature announcement.
When a traffic reduction is required due to an overload condition and When a traffic reduction is required due to an overload condition and
the overload control solution is supported by the sender of the the overload control solution is supported by the sender of the
Diameter request, the reporting node MUST include an OC-Supported- Diameter request, the reporting node MUST include an OC-Supported-
Features AVP and an OC-OLR AVP in the corresponding Diameter answer. Features AVP and an OC-OLR AVP in the corresponding Diameter answer.
The OC-OLR AVP contains the required traffic reduction and the OC- The OC-OLR AVP contains the required traffic reduction and the OC-
Supported-Features AVP indicates the traffic abatement algorithm to Supported-Features AVP indicates the traffic abatement algorithm to
apply. This algorithm MUST be one of the algorithms advertised by apply. This algorithm MUST be one of the algorithms advertised by
the request sender. the request sender.
skipping to change at page 27, line 36 skipping to change at page 27, line 36
reporting node. For example, the reacting node may indicate which reporting node. For example, the reacting node may indicate which
(future defined) traffic abatement algorithms it supports in addition (future defined) traffic abatement algorithms it supports in addition
to the default. to the default.
During the message exchange the DOIC nodes express their common set During the message exchange the DOIC nodes express their common set
of supported capabilities. The reacting node includes the OC- of supported capabilities. The reacting node includes the OC-
Supported-Features AVP that announces what it supports. The Supported-Features AVP that announces what it supports. The
reporting node that sends the answer also includes the OC-Supported- reporting node that sends the answer also includes the OC-Supported-
Features AVP that describes the capabilities it supports. The set of Features AVP that describes the capabilities it supports. The set of
capabilities advertised by the reporting node depends on local capabilities advertised by the reporting node depends on local
policies. At least one of the announced capabilities MUST match. If policies. Since the loss abatement algorithm Section 5 is mandatory
there is no single matching capability the reacting node MUST act as to implement DOIC can always be enabled between these DOIC nodes.
if it does not implement DOIC and cease inserting any DOIC related
AVPs into any Diameter messages with this specific reacting node.
Editor's note: The last sentence conflicts with the last sentence
two paragraphs up. In reality, there will always be at least one
matching capability as all nodes supporting DOIC must support the
loss algorithm. Suggest removing the last sentence.
6.2. OC-Feature-Vector AVP 6.2. OC-Feature-Vector AVP
The OC-Feature-Vector AVP (AVP code TBD6) is type of Unsigned64 and The OC-Feature-Vector AVP (AVP code TBD6) is type of Unsigned64 and
contains a 64 bit flags field of announced capabilities of a DOIC contains a 64 bit flags field of announced capabilities of a DOIC
node. The value of zero (0) is reserved. node. The value of zero (0) is reserved.
The following capabilities are defined in this document: The following capabilities are defined in this document:
OLR_DEFAULT_ALGO (0x0000000000000001) OLR_DEFAULT_ALGO (0x0000000000000001)
 End of changes. 9 change blocks. 
24 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------050606030204050906070403-- From nobody Mon Oct 20 04:20:27 2014 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 528D91A700A for ; Mon, 20 Oct 2014 02:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 pTf0DjAgQmGr for ; Mon, 20 Oct 2014 02:08:27 -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 33C0E1A1A25 for ; Mon, 20 Oct 2014 02:08:27 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:50583 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xg8wy-0008Dy-NM for dime@ietf.org; Mon, 20 Oct 2014 02:08:26 -0700 Message-ID: <5444D107.1080902@usdonovans.com> Date: Mon, 20 Oct 2014 11:08:23 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------010303030700060706060806" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/G7mohexTFIV8WEqlYGabGwGOGv8 X-Mailman-Approved-At: Mon, 20 Oct 2014 04:19:58 -0700 Subject: [Dime] Resolution to 76 78 79 81 84 checked in 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, 20 Oct 2014 09:08:33 -0000 This is a multi-part message in MIME format. --------------010303030700060706060806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've updated github for the above issues. The diff is attached. Regards, Steve --------------010303030700060706060806 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 2, line 19 skipping to change at page 2, line 19
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 6 3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 6
3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7
3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 9 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 8
3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10
3.5. Simplified Example Architecture . . . . . . . . . . . . . 10 3.5. Simplified Example Architecture . . . . . . . . . . . . . 10
3.6. Considerations for Applications Integrating the DOIC 3.6. Considerations for Applications Integrating the DOIC
Solution . . . . . . . . . . . . . . . . . . . . . . . . 11 Solution . . . . . . . . . . . . . . . . . . . . . . . . 11
3.6.1. Application Classification . . . . . . . . . . . . . 11 3.6.1. Application Classification . . . . . . . . . . . . . 11
3.6.2. Application Type Overload Implications . . . . . . . 12 3.6.2. Application Type Overload Implications . . . . . . . 12
3.6.3. Request Transaction Classification . . . . . . . . . 14 3.6.3. Request Transaction Classification . . . . . . . . . 14
3.6.4. Request Type Overload Implications . . . . . . . . . 14 3.6.4. Request Type Overload Implications . . . . . . . . . 14
4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 16 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 16
4.1. Capability Announcement . . . . . . . . . . . . . . . . . 16 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 16
skipping to change at page 2, line 41 skipping to change at page 2, line 41
4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 17 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 17
4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 18 4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 18
4.2. Overload Report Processing . . . . . . . . . . . . . . . 18 4.2. Overload Report Processing . . . . . . . . . . . . . . . 18
4.2.1. Overload Control State . . . . . . . . . . . . . . . 18 4.2.1. Overload Control State . . . . . . . . . . . . . . . 18
4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 20 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 20
4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 22 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 22
4.2.4. Agent Behavior . . . . . . . . . . . . . . . . . . . 22 4.2.4. Agent Behavior . . . . . . . . . . . . . . . . . . . 22
4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 23 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 23
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 24 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2. Use of OC-Reduction-Percentage AVP . . . . . . . . . . . 25 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 25
5.3. Reporting Node Behavior . . . . . . . . . . . . . . . . . 25 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 25
5.4. Reacting Node Behavior . . . . . . . . . . . . . . . . . 25
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 26 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 26
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 27 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 26
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 27 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 27
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 28 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 27
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 28 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 28
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 29 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 28
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 29 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 29
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 31 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 30
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 31 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 31
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 31
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 31
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 32 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 32
9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 33 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 32
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 34 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 33
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 34 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 34
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 34 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 34
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
11.1. Normative References . . . . . . . . . . . . . . . . . . 36 11.1. Normative References . . . . . . . . . . . . . . . . . . 35
11.2. Informative References . . . . . . . . . . . . . . . . . 36 11.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Issues left for future specifications . . . . . . . 37 Appendix A. Issues left for future specifications . . . . . . . 36
A.1. Additional traffic abatement algorithms . . . . . . . . . 37 A.1. Additional traffic abatement algorithms . . . . . . . . . 36
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 37 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 36
A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 37 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 37
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 37 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 37
B.1. Mix of Destination-Realm routed requests and Destination- B.1. Mix of Destination-Realm routed requests and Destination-
Host routed requests . . . . . . . . . . . . . . . . . . 37 Host routed requests . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This specification defines a base solution for Diameter Overload This specification defines a base solution for Diameter Overload
Control (DOC), refered to as Diameter Overload Indication Conveyance Control (DOC), refered to as Diameter Overload Indication Conveyance
(DOIC). The requirements for the solution are described and (DOIC). The requirements for the solution are described and
discussed in the corresponding design requirements document discussed in the corresponding design requirements document
[RFC7068]. Note that the overload control solution defined in this [RFC7068]. Note that the overload control solution defined in this
specification does not address all the requirements listed in specification does not address all the requirements listed in
[RFC7068]. A number of overload control related features are left [RFC7068]. A number of overload control related features are left
skipping to change at page 19, line 8 skipping to change at page 19, line 8
A reporting node maintains per supported Diameter application and per A reporting node maintains per supported Diameter application and per
supported (and eventually selected) Abatement Algorithm an Overload supported (and eventually selected) Abatement Algorithm an Overload
Control State. Control State.
An Overload Control State may be identified by the pair of An Overload Control State may be identified by the pair of
Application-Id and supported Abatement Algorithm. Application-Id and supported Abatement Algorithm.
The Overload Control State for a given pair of Application and The Overload Control State for a given pair of Application and
Abatement Algorithm could include the information: Abatement Algorithm could include the information:
o Report type
o Sequence number o Sequence number
o Validity Duration and Expiry Time o Validity Duration and Expiry Time
o Algorithm specific input data (e.g. Reduction Percentage for o Algorithm specific input data (e.g. Reduction Percentage for
Loss) Loss)
Overload Control States for reporting nodes containing a validity Overload Control States for reporting nodes containing a validity
duration of 0 sec. should not expire before any previously sent duration of 0 sec. should not expire before any previously sent
(stale) OLR has timed out at any reacting node. (stale) OLR has timed out at any reacting node.
skipping to change at page 25, line 5 skipping to change at page 25, line 5
3. The reacting node determines that an active overload report 3. The reacting node determines that an active overload report
applies to the request. applies to the request.
4. The reacting node determines if abatement should be applied to 4. The reacting node determines if abatement should be applied to
the request. One approach that could be taken would be to select the request. One approach that could be taken would be to select
a random number between 1 and 100. If the random number is less a random number between 1 and 100. If the random number is less
than the indicated reduction percentage then the request is given than the indicated reduction percentage then the request is given
abatement treatment, otherwise the request is given normal abatement treatment, otherwise the request is given normal
routing treatment. routing treatment.
5.2. Use of OC-Reduction-Percentage AVP 5.2. Reporting Node Behavior
A reporting node using the loss algorithm must use the OC-Reduction-
Percentage AVP (Section 6.7 to indicated the desired percentage of
traffic reduction.)
Editor's note: The above duplicates what is in the OC-Reduction-
Percentage AVP section can probably be removed.
5.3. Reporting Node Behavior
The method a reporting nodes uses to determine the amount of traffic The method a reporting nodes uses to determine the amount of traffic
reduction required to address an overload condition is an reduction required to address an overload condition is an
implementation decision. implementation decision.
When a reporting node that has selected the loss abatement algorithm When a reporting node that has selected the loss abatement algorithm
determines the need to request a traffic reduction it must include an determines the need to request a traffic reduction it must include an
OC-OLR AVP in all response messages. OC-OLR AVP in all response messages.
The reporting node must indicate a percentage reduction in the OC- The reporting node must indicate a percentage reduction in the OC-
skipping to change at page 25, line 36 skipping to change at page 25, line 27
The reporting node may change the reduction percentage in subsequent The reporting node may change the reduction percentage in subsequent
overload reports. When doing so the reporting node must conform to overload reports. When doing so the reporting node must conform to
overload report handing specified in Section 4.2.3. overload report handing specified in Section 4.2.3.
When the reporting node determines it no longer needs a reduction in When the reporting node determines it no longer needs a reduction in
traffic the reporting node should send an overload report indicating traffic the reporting node should send an overload report indicating
the overload report is no longer valid, as specified in the overload report is no longer valid, as specified in
Section 4.2.3. Section 4.2.3.
5.4. Reacting Node Behavior 5.3. Reacting Node Behavior
The method a reacting node uses to determine which request messages The method a reacting node uses to determine which request messages
are given abatement treatment is an implementation decision. are given abatement treatment is an implementation decision.
When receiving an OC-OLR in an answer message where the algorithm When receiving an OC-OLR in an answer message where the algorithm
indicated in the OC-Supported-Features AVP is the loss algorithm, the indicated in the OC-Supported-Features AVP is the loss algorithm, the
reacting node must attempt to apply abatement treatment to the reacting node must attempt to apply abatement treatment to the
requested percentage of request messages sent. requested percentage of request messages sent.
Note: the loss algorithm is a stateless algorithm. As a result, Note: the loss algorithm is a stateless algorithm. As a result,
skipping to change at page 26, line 14 skipping to change at page 26, line 5
If reacting node comes out of the 100 percent traffic reduction as a If reacting node comes out of the 100 percent traffic reduction as a
result of the overload report timing out, the following concerns are result of the overload report timing out, the following concerns are
RECOMMENDED to be applied. The reacting node sending the traffic RECOMMENDED to be applied. The reacting node sending the traffic
should be conservative and, for example, first send "probe" messages should be conservative and, for example, first send "probe" messages
to learn the overload condition of the overloaded node before to learn the overload condition of the overloaded node before
converging to any traffic amount/rate decided by the sender. Similar converging to any traffic amount/rate decided by the sender. Similar
concerns apply in all cases when the overload report times out unless concerns apply in all cases when the overload report times out unless
the previous overload report stated 0 percent reduction. the previous overload report stated 0 percent reduction.
Editor's note: Need to add additional guidance to slowly increase
the rate of traffic sent to avoid a sudden spike in traffic, as
the spike in traffic could result in oscillation of the need for
overload control.
If the reacting node does not receive a an OLR in messages sent to If the reacting node does not receive a an OLR in messages sent to
the formally overloaded node then the reacting node should slowly the formally overloaded node then the reacting node should slowly
increase the rate of traffic sent to the overloaded node. increase the rate of traffic sent to the overloaded node.
It is suggested that the reacting node decrease the amount of traffic It is suggested that the reacting node decrease the amount of traffic
given abatement treatment by 20% each second until the reduction is given abatement treatment by 20% each second until the reduction is
completely removed and no traffic is given abatement treatment. completely removed and no traffic is given abatement treatment.
The goal of this behavior is to reduce the probability of overload The goal of this behavior is to reduce the probability of overload
condition thrashing where an immediate transition from 100% condition thrashing where an immediate transition from 100%
skipping to change at page 28, line 40 skipping to change at page 28, line 25
updated after reception of subsequent OC-OLR AVPs with the same updated after reception of subsequent OC-OLR AVPs with the same
sequence number. The default value for the OC-Validity-Duration AVP sequence number. The default value for the OC-Validity-Duration AVP
value is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is value is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is
not present in the OC-OLR AVP, the default value applies. not present in the OC-OLR AVP, the default value applies.
Note that if a Diameter command were to contain multiple OC-OLR AVPs Note that if a Diameter command were to contain multiple OC-OLR AVPs
they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs
with unknown values SHOULD be silently discarded and the event SHOULD with unknown values SHOULD be silently discarded and the event SHOULD
be logged. be logged.
Editor's note: Need to specify what happens when two reports of
the same type are received.
6.4. OC-Sequence-Number AVP 6.4. OC-Sequence-Number AVP
The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64. The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
Its usage in the context of overload control is described in Its usage in the context of overload control is described in
Section 4.2. Section 4.2.
From the functionality point of view, the OC-Sequence-Number AVP MUST From the functionality point of view, the OC-Sequence-Number AVP MUST
be used as a non-volatile increasing counter between two DOIC nodes. be used as a non-volatile increasing counter between two DOIC nodes.
The sequence number is only required to be unique between two DOIC The sequence number is only required to be unique between two DOIC
nodes. Sequence numbers are treated in a uni-directional manner, nodes. Sequence numbers are treated in a uni-directional manner,
skipping to change at page 30, line 43 skipping to change at page 30, line 24
Editor's note: There is still an open issue on the definition of Editor's note: There is still an open issue on the definition of
Realm reports and whether what report types should be supported. Realm reports and whether what report types should be supported.
There is consensus that host reports should be supported. There There is consensus that host reports should be supported. There
is discussion on Realm reports and Realm-Routed-Request reports. is discussion on Realm reports and Realm-Routed-Request reports.
The above definition applies to Realm-Routed-Request reports where The above definition applies to Realm-Routed-Request reports where
Realm reports are defined to apply to all requests that match the Realm reports are defined to apply to all requests that match the
realm, independent of the presence, absence or value of the realm, independent of the presence, absence or value of the
Destination-Host AVP. Destination-Host AVP.
The default value of the OC-Report-Type AVP is 0 (i.e. the host
report).
The OC-Report-Type AVP is envisioned to be useful for situations The OC-Report-Type AVP is envisioned to be useful for situations
where a reacting node needs to apply different overload treatments where a reacting node needs to apply different overload treatments
for different "types" of overload. For example, the reacting node(s) for different "types" of overload. For example, the reacting node(s)
might need to throttle differently requests sent to a specific server might need to throttle differently requests sent to a specific server
(identified by the Destination-Host AVP in the request) and requests (identified by the Destination-Host AVP in the request) and requests
that can be handled by any server in a realm. The example in that can be handled by any server in a realm. The example in
Appendix B.1 illustrates this usage. Appendix B.1 illustrates this usage.
6.7. OC-Reduction-Percentage AVP 6.7. OC-Reduction-Percentage AVP
 End of changes. 17 change blocks. 
41 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------010303030700060706060806-- From nobody Mon Oct 20 04:20:28 2014 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 9EB4C1A7020 for ; Mon, 20 Oct 2014 02:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.79 X-Spam-Level: ** X-Spam-Status: No, score=2.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 YlxQGDIeHfAb for ; Mon, 20 Oct 2014 02:42:22 -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 60EF81A7031 for ; Mon, 20 Oct 2014 02:42:22 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:50660 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xg9Tn-0005b0-Kt for dime@ietf.org; Mon, 20 Oct 2014 02:42:21 -0700 Message-ID: <5444D8F9.9040906@usdonovans.com> Date: Mon, 20 Oct 2014 11:42:17 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------000207010709030507070803" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dDjUdhbgJkx3nb25qzuimuuMSNo X-Mailman-Approved-At: Mon, 20 Oct 2014 04:19:59 -0700 Subject: [Dime] Resolution to issues 70 and 74 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, 20 Oct 2014 09:42:29 -0000 This is a multi-part message in MIME format. --------------000207010709030507070803 Content-Type: multipart/alternative; boundary="------------020401020408000100020202" --------------020401020408000100020202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have removed the examples section and moved the "Application Considerations" section to an appendix. For issue 70 I also added the following wording to section 4.2.3: A reporting node MUST only send overload reports of a type advertised as supported by the reacting node. Note that a reacting node advertises support for the host and realm report types by including the OC-Supported-Features AVP in the request. Support for other report types must be explicitly indicated by a new feature bit in the OC-Feature-Vector AVP. The diff file is attached. Regards, Steve --------------020401020408000100020202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have removed the examples section and moved the "Application Considerations" section to an appendix.

For issue 70 I also added the following wording to section 4.2.3:

   A reporting node MUST only send overload reports of a type advertised
   as supported by the reacting node.

      Note that a reacting node advertises support for the host and
      realm report types by including the OC-Supported-Features AVP in
      the request.  Support for other report types must be explicitly
      indicated by a new feature bit in the OC-Feature-Vector AVP.
The diff file is attached.

Regards,

Steve
--------------020401020408000100020202-- --------------000207010709030507070803 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 2, line 22 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 6 3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 6
3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7
3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 8 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 8
3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10
3.5. Simplified Example Architecture . . . . . . . . . . . . . 10 3.5. Simplified Example Architecture . . . . . . . . . . . . . 10
3.6. Considerations for Applications Integrating the DOIC 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11
Solution . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 11
3.6.1. Application Classification . . . . . . . . . . . . . 11 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12
3.6.2. Application Type Overload Implications . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12
3.6.3. Request Transaction Classification . . . . . . . . . 14 4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 13
3.6.4. Request Type Overload Implications . . . . . . . . . 14 4.2. Overload Report Processing . . . . . . . . . . . . . . . 13
4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Overload Control State . . . . . . . . . . . . . . . 13
4.1. Capability Announcement . . . . . . . . . . . . . . . . . 16 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16
4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 16 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17
4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 17 4.2.4. Agent Behavior . . . . . . . . . . . . . . . . . . . 18
4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 18 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 18
4.2. Overload Report Processing . . . . . . . . . . . . . . . 18 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.1. Overload Control State . . . . . . . . . . . . . . . 18 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 20 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 20
4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 22 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21
4.2.4. Agent Behavior . . . . . . . . . . . . . . . . . . . 22 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 21
4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 23 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 24 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23
5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 25 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 24
5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 25 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 26 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 26 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 27 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 26
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 27 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 28 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 27
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 29 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 31 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 29
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 31 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 30
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 31
9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 32
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 33 Appendix A. Issues left for future specifications . . . . . . . 32
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 34 A.1. Additional traffic abatement algorithms . . . . . . . . . 32
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 34 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 32
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix B. Considerations for Applications Integrating the DOIC
11.1. Normative References . . . . . . . . . . . . . . . . . . 35 Solution . . . . . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 36 B.1. Application Classification . . . . . . . . . . . . . . . 33
Appendix A. Issues left for future specifications . . . . . . . 36 B.2. Application Type Overload Implications . . . . . . . . . 34
A.1. Additional traffic abatement algorithms . . . . . . . . . 36 B.3. Request Transaction Classification . . . . . . . . . . . 35
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 36 B.4. Request Type Overload Implications . . . . . . . . . . . 36
A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 37
B.1. Mix of Destination-Realm routed requests and Destination-
Host routed requests . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This specification defines a base solution for Diameter Overload This specification defines a base solution for Diameter Overload
Control (DOC), refered to as Diameter Overload Indication Conveyance Control (DOC), refered to as Diameter Overload Indication Conveyance
(DOIC). The requirements for the solution are described and (DOIC). The requirements for the solution are described and
discussed in the corresponding design requirements document discussed in the corresponding design requirements document
[RFC7068]. Note that the overload control solution defined in this [RFC7068]. Note that the overload control solution defined in this
specification does not address all the requirements listed in specification does not address all the requirements listed in
[RFC7068]. A number of overload control related features are left [RFC7068]. A number of overload control related features are left
skipping to change at page 11, line 35 skipping to change at page 11, line 35
Figure 1: Simplified architecture choices for overload indication Figure 1: Simplified architecture choices for overload indication
delivery delivery
In Figure 1, the Diameter overload indication can be conveyed (1) In Figure 1, the Diameter overload indication can be conveyed (1)
end-to-end between servers and clients or (2) between servers and end-to-end between servers and clients or (2) between servers and
Diameter agent inside the realm and then between the Diameter agent Diameter agent inside the realm and then between the Diameter agent
and the clients when the Diameter agent acting as back-to-back-agent and the clients when the Diameter agent acting as back-to-back-agent
for DOIC purposes. for DOIC purposes.
3.6. Considerations for Applications Integrating the DOIC Solution
THis section outlines considerations to be taken into account when
integrating the DOIC solution into Diameter applications.
3.6.1. Application Classification
The following is a classification of Diameter applications and
requests. This discussion is meant to document factors that play
into decisions made by the Diameter identity responsible for handling
overload reports.
Section 8.1 of [RFC6733] defines two state machines that imply two
types of applications, session-less and session-based applications.
The primary difference between these types of applications is the
lifetime of Session-Ids.
For session-based applications, the Session-Id is used to tie
multiple requests into a single session.
In session-less applications, the lifetime of the Session-Id is a
single Diameter transaction, i.e. the session is implicitly
terminated after a single Diameter transaction and a new Session-Id
is generated for each Diameter request.
For the purposes of this discussion, session-less applications are
further divided into two types of applications:
Stateless applications:
Requests within a stateless application have no relationship to
each other. The 3GPP defined S13 application is an example of a
stateless application [S13], --> where only a Diameter command is
defined between a client and a server and no state is maintained
between two consecutive transactions.
Pseudo-session applications:
Applications that do not rely on the Session-Id AVP for
correlation of application messages related to the same session
but use other session-related information in the Diameter requests
for this purpose. The 3GPP defined Cx application [Cx] is an
example of a pseudo-session application.
The Credit-Control application defined in [RFC4006] is an example of
a Diameter session-based application.
The handling of overload reports must take the type of application
into consideration, as discussed in Section 3.6.2.
3.6.2. Application Type Overload Implications
This section discusses considerations for mitigating overload
reported by a Diameter entity. This discussion focuses on the type
of application. Section 3.6.3 discusses considerations for handling
various request types when the target server is known to be in an
overloaded state.
These discussions assume that the strategy for mitigating the
reported overload is to reduce the overall workload sent to the
overloaded entity. The concept of applying overload treatment to
requests targeted for an overloaded Diameter entity is inherent to
this discussion. The method used to reduce offered load is not
specified here but could include routing requests to another Diameter
entity known to be able to handle them, or it could mean rejecting
certain requests. For a Diameter agent, rejecting requests will
usually mean generating appropriate Diameter error responses. For a
Diameter client, rejecting requests will depend upon the application.
For example, it could mean giving an indication to the entity
requesting the Diameter service that the network is busy and to try
again later.
Stateless applications:
By definition there is no relationship between individual requests
in a stateless application. As a result, when a request is sent
or relayed to an overloaded Diameter entity - either a Diameter
Server or a Diameter Agent - the sending or relaying entity can
choose to apply the overload treatment to any request targeted for
the overloaded entity.
Pseudo-session applications:
For pseudo-session applications, there is an implied ordering of
requests. As a result, decisions about which requests towards an
overloaded entity to reject could take the command code of the
request into consideration. This generally means that
transactions later in the sequence of transactions should be given
more favorable treatment than messages earlier in the sequence.
This is because more work has already been done by the Diameter
network for those transactions that occur later in the sequence.
Rejecting them could result in increasing the load on the network
as the transactions earlier in the sequence might also need to be
repeated.
Session-based applications:
Overload handling for session-based applications must take into
consideration the work load associated with setting up and
maintaining a session. As such, the entity sending requests
towards an overloaded Diameter entity for a session-based
application might tend to reject new session requests prior to
rejecting intra-session requests. In addition, session ending
requests might be given a lower probability of being rejected as
rejecting session ending requests could result in session status
being out of sync between the Diameter clients and servers.
Application designers that would decide to reject mid-session
requests will need to consider whether the rejection invalidates
the session and any resulting session clean-up procedures.
3.6.3. Request Transaction Classification
Independent Request:
An independent request is not correlated to any other requests
and, as such, the lifetime of the session-id is constrained to an
individual transaction.
Session-Initiating Request:
A session-initiating request is the initial message that
establishes a Diameter session. The ACR message defined in
[RFC6733] is an example of a session-initiating request.
Correlated Session-Initiating Request:
There are cases when multiple session-initiated requests must be
correlated and managed by the same Diameter server. It is notably
the case in the 3GPP PCC architecture [PCC], where multiple
apparently independent Diameter application sessions are actually
correlated and must be handled by the same Diameter server.
Intra-Session Request:
An intra session request is a request that uses the same Session-
Id than the one used in a previous request. An intra session
request generally needs to be delivered to the server that handled
the session creating request for the session. The STR message
defined in [RFC6733] is an example of an intra-session requests.
Pseudo-Session Requests:
Pseudo-session requests are independent requests and do not use
the same Session-Id but are correlated by other session-related
information contained in the request. There exists Diameter
applications that define an expected ordering of transactions.
This sequencing of independent transactions results in a pseudo
session. The AIR, MAR and SAR requests in the 3GPP defined Cx
[Cx] application are examples of pseudo-session requests.
3.6.4. Request Type Overload Implications
The request classes identified in Section 3.6.3 have implications on
decisions about which requests should be throttled first. The
following list of request treatment regarding throttling is provided
as guidelines for application designers when implementing the
Diameter overload control mechanism described in this document. The
exact behavior regarding throttling is a matter of local policy,
unless specifically defined for the application.
Independent requests:
Independent requests can be given equal treatment when making
throttling decisions.
Session-initiating requests:
Session-initiating requests represent more work than independent
or intra-session requests. Moreover, session-initiating requests
are typically followed by other session-related requests. As
such, as the main objective of the overload control is to reduce
the total number of requests sent to the overloaded entity,
throttling decisions might favor allowing intra-session requests
over session-initiating requests. Individual session-initiating
requests can be given equal treatment when making throttling
decisions.
Correlated session-initiating requests:
A Request that results in a new binding, where the binding is used
for routing of subsequent session-initiating requests to the same
server, represents more work load than other requests. As such,
these requests might be throttled more frequently than other
request types.
Pseudo-session requests:
Throttling decisions for pseudo-session requests can take into
consideration where individual requests fit into the overall
sequence of requests within the pseudo session. Requests that are
earlier in the sequence might be throttled more aggressively than
requests that occur later in the sequence.
Intra-session requests
There are two classes of intra-sessions requests. The first class
consists of requests that terminate a session. The second one
contains the set of requests that are used by the Diameter client
and server to maintain the ongoing session state. Session
terminating requests should be throttled less aggressively in
order to gracefully terminate sessions, allow clean-up of the
related resources (e.g. session state) and get rid of the need for
other intra-session requests, reducing the session management
impact on the overloaded entity. The default handling of other
intra-session requests might be to treat them equally when making
throttling decisions. There might also be application level
considerations whether some request types are favored over others.
4. Solution Procedures 4. Solution Procedures
This section outlines the normative behavior associated with the DOIC This section outlines the normative behavior associated with the DOIC
solution. solution.
4.1. Capability Announcement 4.1. Capability Announcement
This section defines DOIC Capability Announcement (DCA) behavior. This section defines DOIC Capability Announcement (DCA) behavior.
The DCA procedures are used to indicate support for DOIC and support The DCA procedures are used to indicate support for DOIC and support
skipping to change at page 22, line 35 skipping to change at page 18, line 16
When a traffic reduction is required due to an overload condition and When a traffic reduction is required due to an overload condition and
the overload control solution is supported by the sender of the the overload control solution is supported by the sender of the
Diameter request, the reporting node MUST include an OC-Supported- Diameter request, the reporting node MUST include an OC-Supported-
Features AVP and an OC-OLR AVP in the corresponding Diameter answer. Features AVP and an OC-OLR AVP in the corresponding Diameter answer.
The OC-OLR AVP contains the required traffic reduction and the OC- The OC-OLR AVP contains the required traffic reduction and the OC-
Supported-Features AVP indicates the traffic abatement algorithm to Supported-Features AVP indicates the traffic abatement algorithm to
apply. This algorithm MUST be one of the algorithms advertised by apply. This algorithm MUST be one of the algorithms advertised by
the request sender. the request sender.
A reporting node MUST only send overload reports of a type advertised
as supported by the reacting node.
Note that a reacting node advertises support for the host and
realm report types by including the OC-Supported-Features AVP in
the request. Support for other report types must be explicitly
indicated by a new feature bit in the OC-Feature-Vector AVP.
A reporting node MAY rely on the OC-Validity-Duration AVP values for A reporting node MAY rely on the OC-Validity-Duration AVP values for
the implicit overload control state cleanup on the reacting node. the implicit overload control state cleanup on the reacting node.
However, it is RECOMMENDED that the reporting node always explicitly However, it is RECOMMENDED that the reporting node always explicitly
indicates the end of a overload condition. indicates the end of a overload condition.
The reporting node SHOULD indicate the end of an overload occurrence The reporting node SHOULD indicate the end of an overload occurrence
by sending a new OLR with OC-Validity-Duration set to a value of zero by sending a new OLR with OC-Validity-Duration set to a value of zero
("0"). The reporting node SHOULD insure that all reacting nodes ("0"). The reporting node SHOULD insure that all reacting nodes
receive the updated overload report. receive the updated overload report.
skipping to change at page 30, line 29 skipping to change at page 26, line 10
The above definition applies to Realm-Routed-Request reports where The above definition applies to Realm-Routed-Request reports where
Realm reports are defined to apply to all requests that match the Realm reports are defined to apply to all requests that match the
realm, independent of the presence, absence or value of the realm, independent of the presence, absence or value of the
Destination-Host AVP. Destination-Host AVP.
The OC-Report-Type AVP is envisioned to be useful for situations The OC-Report-Type AVP is envisioned to be useful for situations
where a reacting node needs to apply different overload treatments where a reacting node needs to apply different overload treatments
for different "types" of overload. For example, the reacting node(s) for different "types" of overload. For example, the reacting node(s)
might need to throttle differently requests sent to a specific server might need to throttle differently requests sent to a specific server
(identified by the Destination-Host AVP in the request) and requests (identified by the Destination-Host AVP in the request) and requests
that can be handled by any server in a realm. The example in that can be handled by any server in a realm.
Appendix B.1 illustrates this usage.
6.7. OC-Reduction-Percentage AVP 6.7. OC-Reduction-Percentage AVP
The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32 The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
and describes the percentage of the traffic that the sender is and describes the percentage of the traffic that the sender is
requested to reduce, compared to what it otherwise would send. The requested to reduce, compared to what it otherwise would send. The
OC-Reduction-Percentage AVP applies to the default (loss) algorithm OC-Reduction-Percentage AVP applies to the default (loss) algorithm
specified in this specification. However, the AVP can be reused for specified in this specification. However, the AVP can be reused for
future abatement algorithms, if its semantics fit into the new future abatement algorithms, if its semantics fit into the new
algorithm. algorithm.
skipping to change at page 37, line 17 skipping to change at page 33, line 17
The current [RFC6733] behavior in a case of DIAMETER_TOO_BUSY is The current [RFC6733] behavior in a case of DIAMETER_TOO_BUSY is
somewhat under specified. For example, there is no information how somewhat under specified. For example, there is no information how
long the specific Diameter node is willing to be unavailable. A long the specific Diameter node is willing to be unavailable. A
specification updating [RFC6733] should clarify the handling of specification updating [RFC6733] should clarify the handling of
DIAMETER_TOO_BUSY from the error answer initiating Diameter node DIAMETER_TOO_BUSY from the error answer initiating Diameter node
point of view and from the original request initiating Diameter node point of view and from the original request initiating Diameter node
point of view. Further, the inclusion of possible additional point of view. Further, the inclusion of possible additional
information providing AVPs should be discussed and possible be information providing AVPs should be discussed and possible be
recommended to be used. recommended to be used.
Appendix B. Examples Appendix B. Considerations for Applications Integrating the DOIC
Solution
B.1. Mix of Destination-Realm routed requests and Destination-Host THis section outlines considerations to be taken into account when
routed requests integrating the DOIC solution into Diameter applications.
Diameter allows a client to optionally select the destination server B.1. Application Classification
of a request, even if there are agents between the client and the
server. The client does this using the Destination-Host AVP. In
cases where the client does not care if a specific server receives
the request, it can omit Destination-Host and route the request using
the Destination-Realm and Application Id, effectively letting an
agent select the server.
Clients commonly send mixtures of Destination-Host and Destination- The following is a classification of Diameter applications and
Realm routed requests. For example, in an application that uses user requests. This discussion is meant to document factors that play
sessions, a client typically won't care which server handles a into decisions made by the Diameter identity responsible for handling
session-initiating requests. But once the session is initiated, the overload reports.
client will send all subsequent requests in that session to the same
server. Therefore it would send the initial request with no
Destination-Host AVP. If it receives a successful answer, the client
would copy the Origin-Host value from the answer message into a
Destination-Host AVP in each subsequent request in the session.
An agent has very limited options in applying overload abatement to Section 8.1 of [RFC6733] defines two state machines that imply two
requests that contain Destination-Host AVPs. It typically cannot types of applications, session-less and session-based applications.
route the request to a different server than the one identified in The primary difference between these types of applications is the
Destination-Host. It's only remaining options are to throttle such lifetime of Session-Ids.
requests locally, or to send an overload report back towards the
client so the client can throttle the requests. The second choice is
usually more efficient, since it prevents any throttled requests from
being sent in the first place, and removes the agent's need to send
errors back to the client for each dropped request.
On the other hand, an agent has much more leeway to apply overload For session-based applications, the Session-Id is used to tie
abatement for requests that do not contain Destination-Host AVPs. If multiple requests into a single session.
the agent has multiple servers in its peer table for the given realm
and application, it can route such requests to other, less overloaded
servers.
If the overload severity increases, the agent may reach a point where In session-less applications, the lifetime of the Session-Id is a
there is not sufficient capacity across all servers to handle even single Diameter transaction, i.e. the session is implicitly
realm-routed requests. In this case, the realm itself can be terminated after a single Diameter transaction and a new Session-Id
considered overloaded. The agent may need the client to throttle is generated for each Diameter request.
realm-routed requests in addition to Destination-Host routed
requests. The overload severity may be different for each server,
and the severity for the realm at is likely to be different than for
any specific server. Therefore, an agent may need to forward, or
originate, multiple overload reports with differing ReportType and
Reduction-Percentage values.
Figure 2 illustrates such a mixed-routing scenario. In this example, For the purposes of this discussion, session-less applications are
the servers S1, S2, and S3 handle requests for the realm "realm". further divided into two types of applications:
Any of the three can handle requests that are not part of a user
session (i.e. routed by Destination-Realm). But once a session is
established, all requests in that session must go to the same server.
Client Agent S1 S2 S3 Stateless applications:
| | | | |
|(1) Request (DR:realm) | |
|-------->| | | |
| | | | |
| | | | |
| |Agent selects S1 | |
| | | | |
| | | | |
| | | | |
| |(2) Request (DR:realm) |
| |-------->| | |
| | | | |
| | | | |
| | |S1 overloaded, returns OLR
| | | | |
| | | | |
| | | | |
| |(3) Answer (OR:realm,OH:S1,OLR:RT=DH)
| |<--------| | |
| | | | |
| | | | |
| |sees OLR,routes DR traffic to S2&S3
| | | | |
| | | | |
| | | | |
|(4) Answer (OR:realm,OH:S1, OLR:RT=DH) |
|<--------| | | |
| | | | |
| | | | |
|Client throttles requests with DH:S1 |
| | | | |
| | | | |
| | | | |
|(5) Request (DR:realm) | |
|-------->| | | |
| | | | |
| | | | |
| |Agent selects S2 | |
| | | | |
| | | | |
| | | | |
| |(6) Request (DR:realm) |
| |------------------>| |
| | | | |
| | | | |
| | | |S2 is overloaded...
| | | | |
| | | | |
| | | | |
| |(7) Answer (OH:S2, OLR:RT=DH)|
| |<------------------| |
| | | | |
| | | | |
| |Agent sees OLR, realm now overloaded
| | | | |
| | | | |
| | | | |
|(8) Answer (OR:realm,OH:S2, OLR:RT=DH, OLR: RT=R)
|<--------| | | |
| | | | |
| | | | |
|Client throttles DH:S1, DH:S2, and DR:realm
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
Figure 2: Mix of Destination-Host and Destination-Realm Routed Requests within a stateless application have no relationship to
Requests each other. The 3GPP defined S13 application is an example of a
stateless application [S13], --> where only a Diameter command is
defined between a client and a server and no state is maintained
between two consecutive transactions.
1. The client sends a request with no Destination-Host AVP (that is, Pseudo-session applications:
a Destination-Realm routed request.)
2. The agent follows local policy to select a server from its peer Applications that do not rely on the Session-Id AVP for
table. In this case, the agent selects S2 and forwards the correlation of application messages related to the same session
request. but use other session-related information in the Diameter requests
for this purpose. The 3GPP defined Cx application [Cx] is an
example of a pseudo-session application.
3. S1 is overloaded. It sends a answer indicating success, but also The Credit-Control application defined in [RFC4006] is an example of
includes an overload report. Since the overload report only a Diameter session-based application.
applies to S1, the ReportType is "Destination-Host".
4. The agent sees the overload report, and records that S1 is The handling of overload reports must take the type of application
overloaded by the value in the Reduction-Percentage AVP. It into consideration, as discussed in Appendix B.2.
begins diverting the indicated percentage of realm-routed traffic
from S1 to S2 and S3. Since it can't divert Destination-Host
routed traffic, it forwards the overload report to the client.
This effectively delegates the throttling of traffic with
Destination-Host:S1 to the client.
5. The client sends another Destination-Realm routed request. B.2. Application Type Overload Implications
6. The agent selects S2, and forwards the request. This section discusses considerations for mitigating overload
reported by a Diameter entity. This discussion focuses on the type
of application. Appendix B.3 discusses considerations for handling
various request types when the target server is known to be in an
overloaded state.
7. It turns out that S2 is also overloaded, perhaps due to all that These discussions assume that the strategy for mitigating the
traffic it took over for S1. S2 returns an successful answer reported overload is to reduce the overall workload sent to the
containing an overload report. Since this report only applies to overloaded entity. The concept of applying overload treatment to
S2, the ReportType is "Destination-Host". requests targeted for an overloaded Diameter entity is inherent to
this discussion. The method used to reduce offered load is not
specified here but could include routing requests to another Diameter
entity known to be able to handle them, or it could mean rejecting
certain requests. For a Diameter agent, rejecting requests will
usually mean generating appropriate Diameter error responses. For a
Diameter client, rejecting requests will depend upon the application.
For example, it could mean giving an indication to the entity
requesting the Diameter service that the network is busy and to try
again later.
8. The agent sees that S2 is also overloaded by the value in Stateless applications:
Reduction-Percentage. This value is probably different than the
value from S1's report. The agent diverts the remaining traffic By definition there is no relationship between individual requests
to S3 as best as it can, but it calculates that the remaining in a stateless application. As a result, when a request is sent
capacity across all three servers is no longer sufficient to or relayed to an overloaded Diameter entity - either a Diameter
handle all of the realm-routed traffic. This means the realm Server or a Diameter Agent - the sending or relaying entity can
itself is overloaded. The realm's overload percentage is most choose to apply the overload treatment to any request targeted for
likely different than that for either S1 or S2. The agent the overloaded entity.
forward's S2's report back to the client in the Diameter answer.
Additionally, the agent generates a new report for the realm of Pseudo-session applications:
"realm", and inserts that report into the answer. The client
throttles requests with Destination-Host:S1 at one rate, requests For pseudo-session applications, there is an implied ordering of
with Destination-Host:S2 at another rate, and requests with no requests. As a result, decisions about which requests towards an
Destination-Host AVP at yet a third rate. (Since S3 has not overloaded entity to reject could take the command code of the
indicated overload, the client does not throttle requests with request into consideration. This generally means that
Destination-Host:S3.) transactions later in the sequence of transactions should be given
more favorable treatment than messages earlier in the sequence.
This is because more work has already been done by the Diameter
network for those transactions that occur later in the sequence.
Rejecting them could result in increasing the load on the network
as the transactions earlier in the sequence might also need to be
repeated.
Session-based applications:
Overload handling for session-based applications must take into
consideration the work load associated with setting up and
maintaining a session. As such, the entity sending requests
towards an overloaded Diameter entity for a session-based
application might tend to reject new session requests prior to
rejecting intra-session requests. In addition, session ending
requests might be given a lower probability of being rejected as
rejecting session ending requests could result in session status
being out of sync between the Diameter clients and servers.
Application designers that would decide to reject mid-session
requests will need to consider whether the rejection invalidates
the session and any resulting session clean-up procedures.
B.3. Request Transaction Classification
Independent Request:
An independent request is not correlated to any other requests
and, as such, the lifetime of the session-id is constrained to an
individual transaction.
Session-Initiating Request:
A session-initiating request is the initial message that
establishes a Diameter session. The ACR message defined in
[RFC6733] is an example of a session-initiating request.
Correlated Session-Initiating Request:
There are cases when multiple session-initiated requests must be
correlated and managed by the same Diameter server. It is notably
the case in the 3GPP PCC architecture [PCC], where multiple
apparently independent Diameter application sessions are actually
correlated and must be handled by the same Diameter server.
Intra-Session Request:
An intra session request is a request that uses the same Session-
Id than the one used in a previous request. An intra session
request generally needs to be delivered to the server that handled
the session creating request for the session. The STR message
defined in [RFC6733] is an example of an intra-session requests.
Pseudo-Session Requests:
Pseudo-session requests are independent requests and do not use
the same Session-Id but are correlated by other session-related
information contained in the request. There exists Diameter
applications that define an expected ordering of transactions.
This sequencing of independent transactions results in a pseudo
session. The AIR, MAR and SAR requests in the 3GPP defined Cx
[Cx] application are examples of pseudo-session requests.
B.4. Request Type Overload Implications
The request classes identified in Appendix B.3 have implications on
decisions about which requests should be throttled first. The
following list of request treatment regarding throttling is provided
as guidelines for application designers when implementing the
Diameter overload control mechanism described in this document. The
exact behavior regarding throttling is a matter of local policy,
unless specifically defined for the application.
Independent requests:
Independent requests can be given equal treatment when making
throttling decisions.
Session-initiating requests:
Session-initiating requests represent more work than independent
or intra-session requests. Moreover, session-initiating requests
are typically followed by other session-related requests. As
such, as the main objective of the overload control is to reduce
the total number of requests sent to the overloaded entity,
throttling decisions might favor allowing intra-session requests
over session-initiating requests. Individual session-initiating
requests can be given equal treatment when making throttling
decisions.
Correlated session-initiating requests:
A Request that results in a new binding, where the binding is used
for routing of subsequent session-initiating requests to the same
server, represents more work load than other requests. As such,
these requests might be throttled more frequently than other
request types.
Pseudo-session requests:
Throttling decisions for pseudo-session requests can take into
consideration where individual requests fit into the overall
sequence of requests within the pseudo session. Requests that are
earlier in the sequence might be throttled more aggressively than
requests that occur later in the sequence.
Intra-session requests
There are two classes of intra-sessions requests. The first class
consists of requests that terminate a session. The second one
contains the set of requests that are used by the Diameter client
and server to maintain the ongoing session state. Session
terminating requests should be throttled less aggressively in
order to gracefully terminate sessions, allow clean-up of the
related resources (e.g. session state) and get rid of the need for
other intra-session requests, reducing the session management
impact on the overloaded entity. The default handling of other
intra-session requests might be to treat them equally when making
throttling decisions. There might also be application level
considerations whether some request types are favored over others.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
Broadcom Broadcom
Porkkalankatu 24 Porkkalankatu 24
Helsinki FIN-00180 Helsinki FIN-00180
Finland Finland
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
Steve Donovan (editor) Steve Donovan (editor)
Oracle Oracle
 End of changes. 23 change blocks. 
418 lines changed or deleted 249 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------000207010709030507070803-- From nobody Mon Oct 20 04:20:30 2014 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 8C7A31A86E8 for ; Mon, 20 Oct 2014 04:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 Rrn3kBhL-ECY for ; Mon, 20 Oct 2014 04:14:51 -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 656CD1A86E9 for ; Mon, 20 Oct 2014 04:14:51 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:51382 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgAvJ-0006qm-Fl for dime@ietf.org; Mon, 20 Oct 2014 04:14:50 -0700 Message-ID: <5444EEA8.500@usdonovans.com> Date: Mon, 20 Oct 2014 13:14:48 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------040105000106000400020103" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/wRiCacROr2kut5srYFttsnts6s4 X-Mailman-Approved-At: Mon, 20 Oct 2014 04:19:59 -0700 Subject: [Dime] Resolution to #72 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, 20 Oct 2014 11:14:54 -0000 This is a multi-part message in MIME format. --------------040105000106000400020103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've updated github to reflect changes to #72. I've attached the resulting diff file. Regards, Steve --------------040105000106000400020103 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 2, line 32 skipping to change at page 2, line 32
4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11
4.1. Capability Announcement . . . . . . . . . . . . . . . . . 11 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 11
4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12
4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12
4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 13 4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 13
4.2. Overload Report Processing . . . . . . . . . . . . . . . 13 4.2. Overload Report Processing . . . . . . . . . . . . . . . 13
4.2.1. Overload Control State . . . . . . . . . . . . . . . 13 4.2.1. Overload Control State . . . . . . . . . . . . . . . 13
4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16
4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17
4.2.4. Agent Behavior . . . . . . . . . . . . . . . . . . . 18 4.2.4. Agent Behavior . . . . . . . . . . . . . . . . . . . 18
4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 18 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 19
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 19 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 20 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 21
5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 21 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 22
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 24 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 24
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 26 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 29 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 29
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 30 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 30
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
skipping to change at page 18, line 9 skipping to change at page 18, line 9
The operation on the reporting node is straight forward. The The operation on the reporting node is straight forward. The
reporting node learns the capabilities of the reacting node when it reporting node learns the capabilities of the reacting node when it
receives the OC-Supported-Features AVP as part of any Diameter receives the OC-Supported-Features AVP as part of any Diameter
request message. Since the loss abatement algorithm Section 5 is request message. Since the loss abatement algorithm Section 5 is
mandatory to implement DOIC can always be enabled between these DOIC mandatory to implement DOIC can always be enabled between these DOIC
nodes See Section 4.1 for further discussion on the capability and nodes See Section 4.1 for further discussion on the capability and
feature announcement. feature announcement.
When a traffic reduction is required due to an overload condition and When a traffic reduction is required due to an overload condition and
the overload control solution is supported by the sender of the the overload control solution is supported by the sender of the
Diameter request, the reporting node MUST include an OC-Supported- Diameter request, the reporting node SHOULD include an OC-Supported-
Features AVP and an OC-OLR AVP in the corresponding Diameter answer. Features AVP and an OC-OLR AVP in the corresponding Diameter answer.
A reporting node MAY choose to not send an overload report to a
reacting node if it can guarantee that this overload report is
already active in the reacting node.
Note - In some cases (e.g. when there are one or multiple agents
in the path between reporting and reacting nodes, or when overload
reports are discarded by reacting nodes) the reporting node may
not be able to guarantee that the reacting node has received the
report.
The OC-OLR AVP contains the required traffic reduction and the OC- The OC-OLR AVP contains the required traffic reduction and the OC-
Supported-Features AVP indicates the traffic abatement algorithm to Supported-Features AVP indicates the traffic abatement algorithm to
apply. This algorithm MUST be one of the algorithms advertised by apply. This algorithm MUST be one of the algorithms advertised by
the request sender. the request sender.
A reporting node MUST only send overload reports of a type advertised A reporting node MUST only send overload reports of a type advertised
as supported by the reacting node. as supported by the reacting node.
Note that a reacting node advertises support for the host and Note that a reacting node advertises support for the host and
realm report types by including the OC-Supported-Features AVP in realm report types by including the OC-Supported-Features AVP in
skipping to change at page 20, line 39 skipping to change at page 21, line 12
abatement treatment, otherwise the request is given normal abatement treatment, otherwise the request is given normal
routing treatment. routing treatment.
5.2. Reporting Node Behavior 5.2. Reporting Node Behavior
The method a reporting nodes uses to determine the amount of traffic The method a reporting nodes uses to determine the amount of traffic
reduction required to address an overload condition is an reduction required to address an overload condition is an
implementation decision. implementation decision.
When a reporting node that has selected the loss abatement algorithm When a reporting node that has selected the loss abatement algorithm
determines the need to request a traffic reduction it must include an determines the need to request a traffic reduction it includes an OC-
OC-OLR AVP in all response messages. OLR AVP in response messages as described in Section 4.2.3.
The reporting node must indicate a percentage reduction in the OC- The reporting node must indicate a percentage reduction in the OC-
Reduction-Percentage AVP. Reduction-Percentage AVP.
The reporting node may change the reduction percentage in subsequent The reporting node may change the reduction percentage in subsequent
overload reports. When doing so the reporting node must conform to overload reports. When doing so the reporting node must conform to
overload report handing specified in Section 4.2.3. overload report handing specified in Section 4.2.3.
When the reporting node determines it no longer needs a reduction in When the reporting node determines it no longer needs a reduction in
traffic the reporting node should send an overload report indicating traffic the reporting node should send an overload report indicating
 End of changes. 6 change blocks. 
9 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------040105000106000400020103-- From nobody Mon Oct 20 04:33:58 2014 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 422E81A86F4 for ; Mon, 20 Oct 2014 04:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gEeB1HEjkaWH for ; Mon, 20 Oct 2014 04:33:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 F2B141A802B for ; Mon, 20 Oct 2014 04:33:54 -0700 (PDT) Received: from localhost ([::1]:43961 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgBDj-0001VZ-BM; Mon, 20 Oct 2014 04:33:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 11:33:51 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/73#comment:1 Message-ID: <096.f80f9ea65f9ce677eb90d2e23b0f28d9@trac.tools.ietf.org> References: <081.1b4a897dcd07e50c4d2a8df5bb419ded@trac.tools.ietf.org> X-Trac-Ticket-ID: 73 In-Reply-To: <081.1b4a897dcd07e50c4d2a8df5bb419ded@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8cntaCG50rm6aHNPpFSSMpvNhkA Cc: dime@ietf.org Subject: Re: [Dime] [dime] #73 (draft-ietf-dime-ovli): Clarifications On Mbit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 11:33:56 -0000 #73: Clarifications On Mbit Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Based on agreement during the France interim meeting, changed M-bit wording to reference RFC6733. Resulted in modified wording in section 4.3 and section 6. -- -------------------------------------+------------------------------------- Reporter: jean-jacques.trottin | Owner: draft-ietf-dime- @alcatel-lucent.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 04:36:59 2014 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 E7FA91A86EE for ; Mon, 20 Oct 2014 04:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 2Wy643ufOKqd for ; Mon, 20 Oct 2014 04:36:07 -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 28AFF1A86EC for ; Mon, 20 Oct 2014 04:36:07 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:51473 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgBFt-0008sy-5z for dime@ietf.org; Mon, 20 Oct 2014 04:36:06 -0700 Message-ID: <5444F3A4.8030904@usdonovans.com> Date: Mon, 20 Oct 2014 13:36:04 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------000504080006030503010108" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/U0rQBZ4XHPRiFu2DenHefCJXWEg X-Mailman-Approved-At: Mon, 20 Oct 2014 04:36:57 -0700 Subject: [Dime] Resolution of issue 73 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, 20 Oct 2014 11:36:11 -0000 This is a multi-part message in MIME format. --------------000504080006030503010108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've updated github with the resolution of issue 73 on M-bit handling. I also removed the agent behavior sections that should have been deleted when closing issues 60 and 61. I've attached the resulting diff file. Regards, Steve --------------000504080006030503010108 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 2, line 26 skipping to change at page 2, line 26
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 6 3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 6
3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7
3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 8 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 8
3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10
3.5. Simplified Example Architecture . . . . . . . . . . . . . 10 3.5. Simplified Example Architecture . . . . . . . . . . . . . 10
4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11
4.1. Capability Announcement . . . . . . . . . . . . . . . . . 11 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 11
4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12
4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12
4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 13
4.2. Overload Report Processing . . . . . . . . . . . . . . . 13 4.2. Overload Report Processing . . . . . . . . . . . . . . . 13
4.2.1. Overload Control State . . . . . . . . . . . . . . . 13 4.2.1. Overload Control State . . . . . . . . . . . . . . . 13
4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16
4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17
4.2.4. Agent Behavior . . . . . . . . . . . . . . . . . . . 18 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 18
4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 19 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 19
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 20
5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 21
5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 22 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 22
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 24 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 24
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 26
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 29 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 29
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 30 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 30
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
skipping to change at page 13, line 30 skipping to change at page 13, line 30
The reporting node MUST NOT include the OC-Supported-Features AVP, The reporting node MUST NOT include the OC-Supported-Features AVP,
OC-OLR AVP or any other overload control AVPs defined in extension OC-OLR AVP or any other overload control AVPs defined in extension
drafts in response messages for transactions where the request drafts in response messages for transactions where the request
message does not include the OC-Supported-Features AVP. Lack of the message does not include the OC-Supported-Features AVP. Lack of the
OC-Supported-Features AVP in the request message indicates that there OC-Supported-Features AVP in the request message indicates that there
is no reacting node for the transaction. is no reacting node for the transaction.
An agent MAY modify the OC-Supported-Features AVP carried in answer An agent MAY modify the OC-Supported-Features AVP carried in answer
messages. messages.
4.1.3. Agent Behavior
Editor's note -- Need to add this section.
4.2. Overload Report Processing 4.2. Overload Report Processing
4.2.1. Overload Control State 4.2.1. Overload Control State
Both reacting and reporting nodes maintain an overload control state Both reacting and reporting nodes maintain an overload control state
(OCS) for active overload reports. (OCS) for active overload reports.
4.2.1.1. Overload Control State for Reacting Nodes 4.2.1.1. Overload Control State for Reacting Nodes
A reacting node maintains the following OCS per supported Diameter A reacting node maintains the following OCS per supported Diameter
skipping to change at page 18, line 45 skipping to change at page 18, line 45
A reporting node MAY rely on the OC-Validity-Duration AVP values for A reporting node MAY rely on the OC-Validity-Duration AVP values for
the implicit overload control state cleanup on the reacting node. the implicit overload control state cleanup on the reacting node.
However, it is RECOMMENDED that the reporting node always explicitly However, it is RECOMMENDED that the reporting node always explicitly
indicates the end of a overload condition. indicates the end of a overload condition.
The reporting node SHOULD indicate the end of an overload occurrence The reporting node SHOULD indicate the end of an overload occurrence
by sending a new OLR with OC-Validity-Duration set to a value of zero by sending a new OLR with OC-Validity-Duration set to a value of zero
("0"). The reporting node SHOULD insure that all reacting nodes ("0"). The reporting node SHOULD insure that all reacting nodes
receive the updated overload report. receive the updated overload report.
4.2.4. Agent Behavior
Editor's note -- Need to add this section.
4.3. Protocol Extensibility 4.3. Protocol Extensibility
The overload control solution can be extended, e.g. with new traffic The overload control solution can be extended, e.g. with new traffic
abatement algorithms, new report types or other new functionality. abatement algorithms, new report types or other new functionality.
When defining a new extension a new feature bit MUST be defined for When defining a new extension a new feature bit MUST be defined for
the OC-Feature-Vector. This feature bit is used to communicate the OC-Feature-Vector. This feature bit is used to communicate
support for the new feature. support for the new feature.
The extention may also define new AVPs for use in DOIC Capability The extention may also define new AVPs for use in DOIC Capability
Anouncement and for use in DOIC Overload reporting. These new AVP Anouncement and for use in DOIC Overload reporting. These new AVP
should be defined to be extensions to the OC-Supported-Features and should be defined to be extensions to the OC-Supported-Features and
OC-OLR AVPs defined in this document. OC-OLR AVPs defined in this document.
It should be noted that [RFC6733] defined Grouped AVP extension It should be noted that [RFC6733] defined Grouped AVP extension
mechanisms apply. This allows, for example, defining a new feature mechanisms apply. This allows, for example, defining a new feature
that is mandatory to be understood even when piggybacked on an that is mandatory to be understood even when piggybacked on an
existing applications. More specifically, the sub-AVPs inside the existing applications.
OC-Supported-Features and OC-OLR AVP MAY have the M-bit set.
However, when overload control AVPs are piggybacked on top of an
existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED.
The handling of feature bits in the OC-Feature-Vector AVP that are The handling of feature bits in the OC-Feature-Vector AVP that are
not associated with overload abatement algorithms MUST be specified not associated with overload abatement algorithms MUST be specified
by the extensions that define the features. by the extensions that define the features.
When defining new report type values, the corresponding specification When defining new report type values, the corresponding specification
MUST define the semantics of the new report types and how they affect MUST define the semantics of the new report types and how they affect
the OC-OLR AVP handling. The specification MUST also reserve a the OC-OLR AVP handling. The specification MUST also reserve a
corresponding new feature, see the OC-Supported-Features and OC- corresponding new feature, see the OC-Supported-Features and OC-
Feature-Vector AVPs. Feature-Vector AVPs.
skipping to change at page 22, line 31 skipping to change at page 22, line 18
Overload Indication Attribute Value Pairs (AVPs) defined in this Overload Indication Attribute Value Pairs (AVPs) defined in this
document. document.
When added to existing commands, both OC-Feature-Vector and OC-OLR When added to existing commands, both OC-Feature-Vector and OC-OLR
AVPs SHOULD have the M-bit flag cleared to avoid backward AVPs SHOULD have the M-bit flag cleared to avoid backward
compatibility issues. compatibility issues.
A new application specification can incorporate the overload control A new application specification can incorporate the overload control
mechanism specified in this document by making it mandatory to mechanism specified in this document by making it mandatory to
implement for the application and referencing this specification implement for the application and referencing this specification
normatively. In such a case, the OC-Feature-Vector and OC-OLR AVPs normatively. In such a case, the rules for handling of the M-bit
reused in newly defined Diameter applications SHOULD have the M-bit must follow the guidance in [RFC6733]. It is the responsibility of
flag set. However, it is the responsibility of the Diameter the Diameter application designers to define how overload control
application designers to define how overload control mechanisms works mechanisms works on that application.
on that application.
6.1. OC-Supported-Features AVP 6.1. OC-Supported-Features AVP
The OC-Supported-Features AVP (AVP code TBD1) is type of Grouped and The OC-Supported-Features AVP (AVP code TBD1) is type of Grouped and
serves for two purposes. First, it announces a node's support for serves for two purposes. First, it announces a node's support for
the DOIC in general. Second, it contains the description of the the DOIC in general. Second, it contains the description of the
supported DOIC features of the sending node. The OC-Supported- supported DOIC features of the sending node. The OC-Supported-
Features AVP MUST be included in every Diameter message a DOIC Features AVP MUST be included in every Diameter message a DOIC
supporting node sends. supporting node sends.
 End of changes. 7 change blocks. 
24 lines changed or deleted 10 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------000504080006030503010108-- From nobody Mon Oct 20 04:54:25 2014 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 57FBC1A8700 for ; Mon, 20 Oct 2014 04:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 g0E_3HNpmiHf for ; Mon, 20 Oct 2014 04:54:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 A5E231A8034 for ; Mon, 20 Oct 2014 04:54:22 -0700 (PDT) Received: from localhost ([::1]:44901 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgBXX-0002mF-IC; Mon, 20 Oct 2014 04:54:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 11:54:19 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/66#comment:1 Message-ID: <072.365b5b87086f75644c491e8483853849@trac.tools.ietf.org> References: <057.235f5e0676a095cce4d25acf9f348309@trac.tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <057.235f5e0676a095cce4d25acf9f348309@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tfTtIeYjRUXocnZnl283SILh4Ak Cc: dime@ietf.org Subject: Re: [Dime] [dime] #66 (draft-ietf-dime-ovli): Non-Supporting Agent Changing Origin-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 11:54:24 -0000 #66: Non-Supporting Agent Changing Origin-Host Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Agreed that the behavior of Topology Hiding agents/proxies is out of scope for this document. Added appendix on deployment consideration with the following wording: Topology hiding interactions There exist proxies that implement what is refered to as Topology Hiding. This can include cases where the agent modifies the Origin-Host in answer messages. The behavior of the DOIC solution is not well understood when this happens. As such, the DOIC solution does not address this scenario. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf- | Version: 2.0 dime-ovli | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Mon Oct 20 04:58:56 2014 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 9866E1A86F7 for ; Mon, 20 Oct 2014 04:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 1I7wdU64Gvug for ; Mon, 20 Oct 2014 04:56:41 -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 E9BA61A8034 for ; Mon, 20 Oct 2014 04:56:40 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:51553 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgBZm-000A1m-NF for dime@ietf.org; Mon, 20 Oct 2014 04:56:39 -0700 Message-ID: <5444F875.3050703@usdonovans.com> Date: Mon, 20 Oct 2014 13:56:37 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------030807000405040100000606" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/00-czQ9lXa1WskIFl_W_Kz1bqak X-Mailman-Approved-At: Mon, 20 Oct 2014 04:58:55 -0700 Subject: [Dime] Resolution to issue #66 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, 20 Oct 2014 11:56:44 -0000 This is a multi-part message in MIME format. --------------030807000405040100000606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have updated github with the changes for issue #66. I added an appendix for "deployment considerations" for this issue and a non supporting agents issue. The text can be found in the attached diff file. Regards, Steve --------------030807000405040100000606 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 3, line 13 skipping to change at page 3, line 13
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 30 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 30
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Issues left for future specifications . . . . . . . 32 Appendix A. Issues left for future specifications . . . . . . . 32
A.1. Additional traffic abatement algorithms . . . . . . . . . 32 A.1. Additional traffic abatement algorithms . . . . . . . . . 32
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 32 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 32
A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 33 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 33
Appendix B. Considerations for Applications Integrating the DOIC Appendix B. Deployment Considerations . . . . . . . . . . . . . 33
Appendix C. Considerations for Applications Integrating the DOIC
Solution . . . . . . . . . . . . . . . . . . . . . . 33 Solution . . . . . . . . . . . . . . . . . . . . . . 33
B.1. Application Classification . . . . . . . . . . . . . . . 33 C.1. Application Classification . . . . . . . . . . . . . . . 33
B.2. Application Type Overload Implications . . . . . . . . . 34 C.2. Application Type Overload Implications . . . . . . . . . 34
B.3. Request Transaction Classification . . . . . . . . . . . 35 C.3. Request Transaction Classification . . . . . . . . . . . 36
B.4. Request Type Overload Implications . . . . . . . . . . . 36 C.4. Request Type Overload Implications . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This specification defines a base solution for Diameter Overload This specification defines a base solution for Diameter Overload
Control (DOC), refered to as Diameter Overload Indication Conveyance Control (DOC), refered to as Diameter Overload Indication Conveyance
(DOIC). The requirements for the solution are described and (DOIC). The requirements for the solution are described and
discussed in the corresponding design requirements document discussed in the corresponding design requirements document
[RFC7068]. Note that the overload control solution defined in this [RFC7068]. Note that the overload control solution defined in this
specification does not address all the requirements listed in specification does not address all the requirements listed in
[RFC7068]. A number of overload control related features are left [RFC7068]. A number of overload control related features are left
skipping to change at page 33, line 17 skipping to change at page 33, line 17
The current [RFC6733] behavior in a case of DIAMETER_TOO_BUSY is The current [RFC6733] behavior in a case of DIAMETER_TOO_BUSY is
somewhat under specified. For example, there is no information how somewhat under specified. For example, there is no information how
long the specific Diameter node is willing to be unavailable. A long the specific Diameter node is willing to be unavailable. A
specification updating [RFC6733] should clarify the handling of specification updating [RFC6733] should clarify the handling of
DIAMETER_TOO_BUSY from the error answer initiating Diameter node DIAMETER_TOO_BUSY from the error answer initiating Diameter node
point of view and from the original request initiating Diameter node point of view and from the original request initiating Diameter node
point of view. Further, the inclusion of possible additional point of view. Further, the inclusion of possible additional
information providing AVPs should be discussed and possible be information providing AVPs should be discussed and possible be
recommended to be used. recommended to be used.
Appendix B. Considerations for Applications Integrating the DOIC Appendix B. Deployment Considerations
Non supporting agents
Due to the way that realm-routed requests are handled in Diameter
networks, with the server selection for the request done by an
agent, it is recommended that deployments upgrade all agents with
direct connections to servers prior to enabling the DOIC solution
in the Diameter network.
Topology hiding interactions
There exist proxies that implement what is refered to as Topology
Hiding. This can include cases where the agent modifies the
Origin-Host in answer messages. The behavior of the DOIC solution
is not well understood when this happens. As such, the DOIC
solution does not address this scenario.
Appendix C. Considerations for Applications Integrating the DOIC
Solution Solution
THis section outlines considerations to be taken into account when THis section outlines considerations to be taken into account when
integrating the DOIC solution into Diameter applications. integrating the DOIC solution into Diameter applications.
B.1. Application Classification C.1. Application Classification
The following is a classification of Diameter applications and The following is a classification of Diameter applications and
requests. This discussion is meant to document factors that play requests. This discussion is meant to document factors that play
into decisions made by the Diameter identity responsible for handling into decisions made by the Diameter identity responsible for handling
overload reports. overload reports.
Section 8.1 of [RFC6733] defines two state machines that imply two Section 8.1 of [RFC6733] defines two state machines that imply two
types of applications, session-less and session-based applications. types of applications, session-less and session-based applications.
The primary difference between these types of applications is the The primary difference between these types of applications is the
lifetime of Session-Ids. lifetime of Session-Ids.
skipping to change at page 34, line 17 skipping to change at page 34, line 36
Applications that do not rely on the Session-Id AVP for Applications that do not rely on the Session-Id AVP for
correlation of application messages related to the same session correlation of application messages related to the same session
but use other session-related information in the Diameter requests but use other session-related information in the Diameter requests
for this purpose. The 3GPP defined Cx application [Cx] is an for this purpose. The 3GPP defined Cx application [Cx] is an
example of a pseudo-session application. example of a pseudo-session application.
The Credit-Control application defined in [RFC4006] is an example of The Credit-Control application defined in [RFC4006] is an example of
a Diameter session-based application. a Diameter session-based application.
The handling of overload reports must take the type of application The handling of overload reports must take the type of application
into consideration, as discussed in Appendix B.2. into consideration, as discussed in Appendix C.2.
B.2. Application Type Overload Implications C.2. Application Type Overload Implications
This section discusses considerations for mitigating overload This section discusses considerations for mitigating overload
reported by a Diameter entity. This discussion focuses on the type reported by a Diameter entity. This discussion focuses on the type
of application. Appendix B.3 discusses considerations for handling of application. Appendix C.3 discusses considerations for handling
various request types when the target server is known to be in an various request types when the target server is known to be in an
overloaded state. overloaded state.
These discussions assume that the strategy for mitigating the These discussions assume that the strategy for mitigating the
reported overload is to reduce the overall workload sent to the reported overload is to reduce the overall workload sent to the
overloaded entity. The concept of applying overload treatment to overloaded entity. The concept of applying overload treatment to
requests targeted for an overloaded Diameter entity is inherent to requests targeted for an overloaded Diameter entity is inherent to
this discussion. The method used to reduce offered load is not this discussion. The method used to reduce offered load is not
specified here but could include routing requests to another Diameter specified here but could include routing requests to another Diameter
entity known to be able to handle them, or it could mean rejecting entity known to be able to handle them, or it could mean rejecting
skipping to change at page 35, line 32 skipping to change at page 36, line 5
towards an overloaded Diameter entity for a session-based towards an overloaded Diameter entity for a session-based
application might tend to reject new session requests prior to application might tend to reject new session requests prior to
rejecting intra-session requests. In addition, session ending rejecting intra-session requests. In addition, session ending
requests might be given a lower probability of being rejected as requests might be given a lower probability of being rejected as
rejecting session ending requests could result in session status rejecting session ending requests could result in session status
being out of sync between the Diameter clients and servers. being out of sync between the Diameter clients and servers.
Application designers that would decide to reject mid-session Application designers that would decide to reject mid-session
requests will need to consider whether the rejection invalidates requests will need to consider whether the rejection invalidates
the session and any resulting session clean-up procedures. the session and any resulting session clean-up procedures.
B.3. Request Transaction Classification C.3. Request Transaction Classification
Independent Request: Independent Request:
An independent request is not correlated to any other requests An independent request is not correlated to any other requests
and, as such, the lifetime of the session-id is constrained to an and, as such, the lifetime of the session-id is constrained to an
individual transaction. individual transaction.
Session-Initiating Request: Session-Initiating Request:
A session-initiating request is the initial message that A session-initiating request is the initial message that
skipping to change at page 36, line 23 skipping to change at page 36, line 45
Pseudo-Session Requests: Pseudo-Session Requests:
Pseudo-session requests are independent requests and do not use Pseudo-session requests are independent requests and do not use
the same Session-Id but are correlated by other session-related the same Session-Id but are correlated by other session-related
information contained in the request. There exists Diameter information contained in the request. There exists Diameter
applications that define an expected ordering of transactions. applications that define an expected ordering of transactions.
This sequencing of independent transactions results in a pseudo This sequencing of independent transactions results in a pseudo
session. The AIR, MAR and SAR requests in the 3GPP defined Cx session. The AIR, MAR and SAR requests in the 3GPP defined Cx
[Cx] application are examples of pseudo-session requests. [Cx] application are examples of pseudo-session requests.
B.4. Request Type Overload Implications C.4. Request Type Overload Implications
The request classes identified in Appendix B.3 have implications on The request classes identified in Appendix C.3 have implications on
decisions about which requests should be throttled first. The decisions about which requests should be throttled first. The
following list of request treatment regarding throttling is provided following list of request treatment regarding throttling is provided
as guidelines for application designers when implementing the as guidelines for application designers when implementing the
Diameter overload control mechanism described in this document. The Diameter overload control mechanism described in this document. The
exact behavior regarding throttling is a matter of local policy, exact behavior regarding throttling is a matter of local policy,
unless specifically defined for the application. unless specifically defined for the application.
Independent requests: Independent requests:
Independent requests can be given equal treatment when making Independent requests can be given equal treatment when making
 End of changes. 10 change blocks. 
14 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------030807000405040100000606-- From nobody Mon Oct 20 05:17:09 2014 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 18B0C1A8545 for ; Mon, 20 Oct 2014 05:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ih7LTxktGRHU for ; Mon, 20 Oct 2014 05:17:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 847401A8033 for ; Mon, 20 Oct 2014 05:17:05 -0700 (PDT) Received: from localhost ([::1]:46022 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgBtT-0007b4-RP; Mon, 20 Oct 2014 05:16:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 12:16:59 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/67#comment:1 Message-ID: <090.1087e6a5bc5310de84b729430627819a@trac.tools.ietf.org> References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> X-Trac-Ticket-ID: 67 In-Reply-To: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/IF4Co7fRkQWSqHXtmIJHprfEr98 Cc: dime@ietf.org Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 12:17:07 -0000 #67: OCS for Reporting Nodes - Expiry Time Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: From notes: Summary: in the current text describing the OCS information elements, it is said that Validity Duration and expiry time need to maintained, whereas actually only the expiry time is required to manage the OCS, this information element derived from the validation time received in the OLR. output of the discussion: It was agreed that OCS information discussed in the draft is given as illustration of data required to manage the OCS in reporting/reacting node and this does not imply that each of information element needs to be locally stored. For instance, some data element can be derived from others. It was also discussed how many times a reporting node needs to send an OLR with the validation duration set to "0" to indicate that the overload situation is over. It was agreed that the reporting node has to send the OLR with validation duration "0" as long as all the reacting maintaining a corresponding active OCS have received the OLR. If there is a way for the reporting node to ensure that all the nodes will receive the OLR as soon as sent, the OLR can be sent only once. Changed one editor's note in section 4.2.1.3, removed the other editor's note. Added the following to section 4.2.3: All OLRs sent have an expiration time calculated by adding the validity-duration contained in the OLR to the time the message was sent. Transit time for the OLR can be safely ignored. The reporting node can ensure that all reacting nodes have received the OLR by continuing to send it in answer messages until the expiration time for all OLRs sent for that overload contition have expired. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 06:26:31 2014 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 6CE251A8797 for ; Mon, 20 Oct 2014 06:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 DD9XJHPDJWrz for ; Mon, 20 Oct 2014 06:26:25 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49341A8825 for ; Mon, 20 Oct 2014 06:23:44 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-a2-54450cde42cb Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 5A.64.04081.EDC05445; Mon, 20 Oct 2014 15:23:42 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.145]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Mon, 20 Oct 2014 15:23:42 +0200 From: Maria Cruz Bartolome To: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" , "srdonovan@usdonovans.com" Thread-Topic: [Dime] [dime] #71 (draft-ietf-dime-ovli): Active overload report even if OC-OLR is not received Thread-Index: AQHP7EKt/SarZzfqDECgPAD4qyDOpJw4+X4w Date: Mon, 20 Oct 2014 13:23:42 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920984E7B7@ESESSMB101.ericsson.se> References: <075.42ce9b1c1c8c40b23a5717c66ad4bd65@trac.tools.ietf.org> <090.9ebd4d96e50723be516d374d27c082b4@trac.tools.ietf.org> In-Reply-To: <090.9ebd4d96e50723be516d374d27c082b4@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje49HtcQg/0TzS3m9q5gs1h+vIHZ YkMTjwOzx5IlP5k8vlz+zOax6m0fawBzFJdNSmpOZllqkb5dAlfGj8OtrAUbuSvubX7O2MD4 nqOLkZNDQsBEYvr0CewQtpjEhXvr2boYuTiEBI4ySvy7tZ0ZwlnCKLH77yZWkCo2ATuJS6df MIEkRARWM0pcOHKIGSQhLJAnsXfHbzYQW0QgX+LZxi9MELaRxLPeiywgNouAqsSzhndgcV4B X4lbrfuYIDY0M0osPXINrIhTwF2iZ+57RhCbEeim76fWgDUwC4hL3HoynwniVgGJJXvOM0PY ohIvH/9jhbAVJT6+2scIUa8jsWD3JzYIW1ti2cLXzBCLBSVOznzCMoFRdBaSsbOQtMxC0jIL ScsCRpZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIHxc3DLb4MdjC+fOx5iFOBgVOLhXZDj EiLEmlhWXJl7iFGag0VJnHfhuXnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhg3fI/eZCid zWayOtBRzqJ5hkEiJ0vmVjY5y4MVt+4d+vb3LeOHT+9zdnvVbbsX3Dj3y18OU+WVd2/HqEu7 PpBnOF7a28q1VrjwtGi+60WHKYtf+/j0Lc7hZWPN/+63dOmTCTKM7vm3p9Y3zN274d306Tsa jq/JvhNmdEmFtySqZE/r0+7GBEclluKMREMt5qLiRACrFBB0gAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/JA32QUVprHZNUKyb4wDSwU-NpYc Subject: Re: [Dime] [dime] #71 (draft-ietf-dime-ovli): Active overload report even if OC-OLR is not received 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, 20 Oct 2014 13:26:27 -0000 Hello, "suggested text" is not included in the ticket info Regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker Sent: lunes, 20 de octubre de 2014 10:49 To: draft-ietf-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com Cc: dime@ietf.org Subject: Re: [Dime] [dime] #71 (draft-ietf-dime-ovli): Active overload repo= rt even if OC-OLR is not received #71: Active overload report even if OC-OLR is not received Changes (by srdonovan@usdonovans.com): * status: new =3D> closed * resolution: =3D> fixed Comment: Updated with the above suggested wording. --=20 -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Mon Oct 20 06:54:01 2014 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 EB90C1A8766 for ; Mon, 20 Oct 2014 06:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-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 zgRgBOeoSDYT for ; Mon, 20 Oct 2014 06:53:54 -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 CDF631A8725 for ; Mon, 20 Oct 2014 06:53:26 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:52301 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgDOg-0007wn-O9; Mon, 20 Oct 2014 06:53:25 -0700 Message-ID: <544513CD.3030406@usdonovans.com> Date: Mon, 20 Oct 2014 15:53:17 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Maria Cruz Bartolome , "dime@ietf.org" References: <075.42ce9b1c1c8c40b23a5717c66ad4bd65@trac.tools.ietf.org> <090.9ebd4d96e50723be516d374d27c082b4@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B920984E7B7@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920984E7B7@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AbXUtOzrD9RRCG53owcu4mWJPLY Subject: Re: [Dime] [dime] #71 (draft-ietf-dime-ovli): Active overload report even if OC-OLR is not received 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, 20 Oct 2014 13:53:56 -0000 The update was based on the suggested wording in the problem report. Steve On 10/20/14, 3:23 PM, Maria Cruz Bartolome wrote: > Hello, > > "suggested text" is not included in the ticket info > Regards > /MCruz > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker > Sent: lunes, 20 de octubre de 2014 10:49 > To: draft-ietf-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com > Cc: dime@ietf.org > Subject: Re: [Dime] [dime] #71 (draft-ietf-dime-ovli): Active overload report even if OC-OLR is not received > > #71: Active overload report even if OC-OLR is not received > > Changes (by srdonovan@usdonovans.com): > > * status: new => closed > * resolution: => fixed > > > Comment: > > Updated with the above suggested wording. > From nobody Mon Oct 20 07:23:24 2014 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 748751A8881 for ; Mon, 20 Oct 2014 07:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iwr0cshnHez6 for ; Mon, 20 Oct 2014 07:23:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 EBEE41A8883 for ; Mon, 20 Oct 2014 07:07:12 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9KE7BA7046640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 09:07:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <072.365b5b87086f75644c491e8483853849@trac.tools.ietf.org> Date: Mon, 20 Oct 2014 09:07:11 -0500 X-Mao-Original-Outgoing-Id: 435506831.566042-02a307fa33fec34cf14a823f274369d2 Content-Transfer-Encoding: quoted-printable Message-Id: <8BAFA865-71FD-4020-993F-DF21005CD73B@nostrum.com> References: <057.235f5e0676a095cce4d25acf9f348309@trac.tools.ietf.org> <072.365b5b87086f75644c491e8483853849@trac.tools.ietf.org> To: dime@ietf.org X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hO7W7d5nJ0DygY1dKhi6FpD2DzA Cc: draft-ietf-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #66 (draft-ietf-dime-ovli): Non-Supporting Agent Changing Origin-Host 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, 20 Oct 2014 14:23:20 -0000 I thought we were going to distinguish between DOIC supporting and = non-supporting proxies. Specifically, a DOIC supporting proxy that = performs topology hiding needs to ensure that any OLRs are appropriate = in the context of the answer in which they are sent. > On Oct 20, 2014, at 6:54 AM, dime issue tracker = wrote: >=20 > #66: Non-Supporting Agent Changing Origin-Host >=20 > Changes (by srdonovan@usdonovans.com): >=20 > * status: new =3D> closed > * resolution: =3D> fixed >=20 >=20 > Comment: >=20 > Agreed that the behavior of Topology Hiding agents/proxies is out of = scope > for this document. >=20 > Added appendix on deployment consideration with the following wording: >=20 > Topology hiding interactions >=20 > There exist proxies that implement what is refered to as = Topology > Hiding. This can include cases where the agent modifies the > Origin-Host in answer messages. The behavior of the DOIC = solution > is not well understood when this happens. As such, the DOIC > solution does not address this scenario. >=20 > --=20 > = -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-ietf-dime- > ben@nostrum.com | ovli@tools.ietf.org > Type: defect | Status: closed > Priority: major | Milestone: > Component: draft-ietf- | Version: 2.0 > dime-ovli | Resolution: fixed > Severity: Active WG | > Document | > Keywords: | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: = > dime >=20 From nobody Mon Oct 20 07:26:27 2014 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 4E8931A8AC5 for ; Mon, 20 Oct 2014 07:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Vgk1y4ae3Jv8 for ; Mon, 20 Oct 2014 07:26:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 239F41A8AC7 for ; Mon, 20 Oct 2014 07:08:34 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9KE8Xu8046755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 09:08:33 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <090.79cda897b8f03e5e7b73357b5d1b2347@trac.tools.ietf.org> Date: Mon, 20 Oct 2014 09:08:32 -0500 X-Mao-Original-Outgoing-Id: 435506912.883985-492390ce42cced9b9ea2d9baa7894368 Content-Transfer-Encoding: quoted-printable Message-Id: References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <090.79cda897b8f03e5e7b73357b5d1b2347@trac.tools.ietf.org> To: dime@ietf.org X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/aJY4wuQv1cKDZ3cOD4hnRPOPdrU Cc: draft-ietf-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received 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, 20 Oct 2014 14:26:22 -0000 I suggest changing "send" to "resend" > On Oct 20, 2014, at 6:11 AM, dime issue tracker = wrote: >=20 > #72: Reporting Node Behaviour when OC-OLR is not received >=20 > Changes (by srdonovan@usdonovans.com): >=20 > * status: new =3D> closed > * resolution: =3D> fixed >=20 >=20 > Comment: >=20 > Added the following to section 4.2.3 per previous email discussions: >=20 > A reporting node MAY choose to not send an overload report to a > reacting node if it can guarantee that this overload report is > already active in the reacting node. >=20 > Note - In some cases (e.g. when there are one or multiple agents > in the path between reporting and reacting nodes, or when = overload > reports are discarded by reacting nodes) the reporting node may > not be able to guarantee that the reacting node has received the > report. >=20 > Also changed wording in the loss section reporting node behavior = section > to refer to section 4.2.3. >=20 > --=20 > = -------------------------------------+------------------------------------= - > Reporter: | Owner: draft-ietf-dime- > maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org > Type: enhancement | Status: closed > Priority: minor | Milestone: > Component: draft-ietf-dime-ovli | Version: > Severity: Active WG Document | Resolution: fixed > Keywords: | > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: = > dime >=20 From nobody Mon Oct 20 07:40:55 2014 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 91BB71A908B for ; Mon, 20 Oct 2014 07:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 w1myQqeFd5ZT for ; Mon, 20 Oct 2014 07:40:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4F7721A87D7 for ; Mon, 20 Oct 2014 07:18:44 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9KEIhg2052344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 09:18:43 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <081.59481ca83ddcf9ab4a68dda3859e21ec@trac.tools.ietf.org> Date: Mon, 20 Oct 2014 09:18:43 -0500 X-Mao-Original-Outgoing-Id: 435507523.0472-20b908177f01d241fbd4435b9da8ca8b Content-Transfer-Encoding: quoted-printable Message-Id: <7351BCD3-8FF0-4485-9110-66C3C07CBB06@nostrum.com> References: <066.8ce734c1c66c770a886774c6bf72f7be@trac.tools.ietf.org> <081.59481ca83ddcf9ab4a68dda3859e21ec@trac.tools.ietf.org> To: dime@ietf.org X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YEF4bVL7sxklF3bdcA7Nonqlglo Cc: draft-ietf-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #85 (draft-ietf-dime-ovli): New error response 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, 20 Oct 2014 14:40:45 -0000 I think the guidance of agents sending unable-to-comply and servers = sending too-busy needs to be pointed out as "typical". There may be = cases where the opposites make sense, e.g., if an agent has reason to = think an alternate route may be ok (as in agent-overload), it might send = too-busy. If a server has reason to believe that the request should not = be retried, it can send unable-to-comply. It's probably best to state this generically based on the expected = result (retrying on different route vs final error.), and then describe = "typical" behavior for agents and servers. > On Oct 20, 2014, at 1:38 AM, dime issue tracker = wrote: >=20 > #85: New error response >=20 >=20 > Comment (by srdonovan@usdonovans.com): >=20 > Raw notes taken from discussion at interim meeting: >=20 > Requirements >=20 > =E2=80=A2 Current Too-Busy behavior allows for retry > =E2=80=A2 Too-Busy was originally defined to have a per = connection scope > =E2=80=A2 MUST only be used when a specific server exists > o This might mean that Too-Busy cannot be used for the throttle > error without updating the definition of Too-Busy behavior > =E2=80=A2 Unable-to-deliver might be another alternative for = throttling > behavior >=20 > =E2=80=A2 Need new error response behavior =E2=80=93 DOIC needs = error response > behavior to prevent retries due to the message being throttled. >=20 > =E2=80=A2 Need to handle case where transaction client supports = the > throttling error behavior and for transaction clients that do not = support > the throttling error behavior. >=20 > Proposal: Use Unable-to-Comply error code when throttling by agent, = too- > busy when throttling by server >=20 > Use case where agent is reacting node =E2=80=93 throttled messages = should result > in Unable-to-Comply >=20 > Use case =E2=80=93 agent throttling when client supports DOIC = unable-to-comply > also works >=20 > Use case =E2=80=93 Server throttling =E2=80=93 too-busy works >=20 > Could add optional =E2=80=9Cerror-diagnostic AVP=E2=80=9D to indicate = the reason for > unable-to-comply =E2=80=93 should be addressed in a separate RFC >=20 > --=20 > = -------------------------------------+------------------------------------= - > Reporter: | Owner: draft-ietf-dime- > srdonovan@usdonovans.com | ovli@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: draft-ietf-dime-ovli | Version: > Severity: Active WG Document | Resolution: > Keywords: | > = -------------------------------------+------------------------------------= - >=20 > Ticket URL: = > dime >=20 From nobody Mon Oct 20 09:26:09 2014 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 A64CF1A8A58 for ; Mon, 20 Oct 2014 09:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HlfrFJrafoCP for ; Mon, 20 Oct 2014 09:26:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 50CE71A6F59 for ; Mon, 20 Oct 2014 09:20:44 -0700 (PDT) Received: from localhost ([::1]:59846 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgFhB-0006aN-HS; Mon, 20 Oct 2014 09:20:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 16:20:33 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/82#comment:1 Message-ID: <081.2761be74612d114c8d5fb57b0dbb104d@trac.tools.ietf.org> References: <066.d3ed74d24b21e564d1e8254e3d1cbd6d@trac.tools.ietf.org> X-Trac-Ticket-ID: 82 In-Reply-To: <066.d3ed74d24b21e564d1e8254e3d1cbd6d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8oqBtB80m18nis6zJK_dBI79Jrc Cc: dime@ietf.org Subject: Re: [Dime] [dime] #82 (draft-ietf-dime-ovli): 6.4. OC-Sequence-Number AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:26:07 -0000 #82: 6.4. OC-Sequence-Number AVP Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Changed to the following: From the functionality point of view, the OC-Sequence-Number AVP MUST be used as a non-volatile increasing counter for a sequence of overload reports between two DOIC nodes for the same overload occurance. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 09:46:01 2014 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 A98731A8762 for ; Mon, 20 Oct 2014 09:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8wI97WvNA17H for ; Mon, 20 Oct 2014 09:45:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 51C511A88C0 for ; Mon, 20 Oct 2014 09:32:24 -0700 (PDT) Received: from localhost ([::1]:60240 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgFsY-0000r1-4k; Mon, 20 Oct 2014 09:32:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Mon, 20 Oct 2014 16:32:18 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/80#comment:1 Message-ID: <081.dc734617273a0925cac7b1f9b5e93e03@trac.tools.ietf.org> References: <066.5539af770d4d4b42fb59894a29e8524f@trac.tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <066.5539af770d4d4b42fb59894a29e8524f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/uko82jbtWNm92egS2HtZeo19mAw Cc: dime@ietf.org Subject: Re: [Dime] [dime] #80 (draft-ietf-dime-ovli): 6.1. OC-Supported-Features AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:45:59 -0000 #80: 6.1. OC-Supported-Features AVP Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Moved behavior to capability announcement section. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Oct 20 09:51:39 2014 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 6E74F1A86F4 for ; Mon, 20 Oct 2014 09:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FsY2hAOxBVib for ; Mon, 20 Oct 2014 09:51:36 -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 E4CB41A86F8 for ; Mon, 20 Oct 2014 09:37:03 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:53081 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgFx6-0000Ct-NG; Mon, 20 Oct 2014 09:37:02 -0700 Message-ID: <54453A2B.4030008@usdonovans.com> Date: Mon, 20 Oct 2014 18:36:59 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell , dime@ietf.org References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <090.79cda897b8f03e5e7b73357b5d1b2347@trac.tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BiEYdNRFc3ATsNDksgFUmCQTqRY Cc: draft-ietf-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received 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, 20 Oct 2014 16:51:37 -0000 Changed as suggested in the latest set of updates, as I happened to be in that section. Steve On 10/20/14, 4:08 PM, Ben Campbell wrote: > I suggest changing "send" to "resend" > >> On Oct 20, 2014, at 6:11 AM, dime issue tracker wrote: >> >> #72: Reporting Node Behaviour when OC-OLR is not received >> >> Changes (by srdonovan@usdonovans.com): >> >> * status: new => closed >> * resolution: => fixed >> >> >> Comment: >> >> Added the following to section 4.2.3 per previous email discussions: >> >> A reporting node MAY choose to not send an overload report to a >> reacting node if it can guarantee that this overload report is >> already active in the reacting node. >> >> Note - In some cases (e.g. when there are one or multiple agents >> in the path between reporting and reacting nodes, or when overload >> reports are discarded by reacting nodes) the reporting node may >> not be able to guarantee that the reacting node has received the >> report. >> >> Also changed wording in the loss section reporting node behavior section >> to refer to section 4.2.3. >> >> -- >> -------------------------------------+------------------------------------- >> Reporter: | Owner: draft-ietf-dime- >> maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org >> Type: enhancement | Status: closed >> Priority: minor | Milestone: >> Component: draft-ietf-dime-ovli | Version: >> Severity: Active WG Document | Resolution: fixed >> Keywords: | >> -------------------------------------+------------------------------------- >> >> Ticket URL: >> dime >> > From nobody Mon Oct 20 10:09:55 2014 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 D7E941A7014 for ; Mon, 20 Oct 2014 10:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ihg1Q7K-SxCj for ; Mon, 20 Oct 2014 10:09:46 -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 696811A6F15 for ; Mon, 20 Oct 2014 09:59:36 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:53111 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgGIm-0009NV-Ec; Mon, 20 Oct 2014 09:59:27 -0700 Message-ID: <54453F6B.1070502@usdonovans.com> Date: Mon, 20 Oct 2014 18:59:23 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell , dime@ietf.org References: <066.8ce734c1c66c770a886774c6bf72f7be@trac.tools.ietf.org> <081.59481ca83ddcf9ab4a68dda3859e21ec@trac.tools.ietf.org> <7351BCD3-8FF0-4485-9110-66C3C07CBB06@nostrum.com> In-Reply-To: <7351BCD3-8FF0-4485-9110-66C3C07CBB06@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/I66aRD6vijgf2RLH6h8HhsD2Fl8 Cc: draft-ietf-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #85 (draft-ietf-dime-ovli): New error response 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, 20 Oct 2014 17:09:48 -0000 Ben, I attempted to treat them generically in the separate email I sent with the title "[Dime] Proposal for error response wording (issue 85)". Does that address your concern? Steve On 10/20/14, 4:18 PM, Ben Campbell wrote: > I think the guidance of agents sending unable-to-comply and servers sending too-busy needs to be pointed out as "typical". There may be cases where the opposites make sense, e.g., if an agent has reason to think an alternate route may be ok (as in agent-overload), it might send too-busy. If a server has reason to believe that the request should not be retried, it can send unable-to-comply. > > It's probably best to state this generically based on the expected result (retrying on different route vs final error.), and then describe "typical" behavior for agents and servers. > >> On Oct 20, 2014, at 1:38 AM, dime issue tracker wrote: >> >> #85: New error response >> >> >> Comment (by srdonovan@usdonovans.com): >> >> Raw notes taken from discussion at interim meeting: >> >> Requirements >> >> • Current Too-Busy behavior allows for retry >> • Too-Busy was originally defined to have a per connection scope >> • MUST only be used when a specific server exists >> o This might mean that Too-Busy cannot be used for the throttle >> error without updating the definition of Too-Busy behavior >> • Unable-to-deliver might be another alternative for throttling >> behavior >> >> • Need new error response behavior – DOIC needs error response >> behavior to prevent retries due to the message being throttled. >> >> • Need to handle case where transaction client supports the >> throttling error behavior and for transaction clients that do not support >> the throttling error behavior. >> >> Proposal: Use Unable-to-Comply error code when throttling by agent, too- >> busy when throttling by server >> >> Use case where agent is reacting node – throttled messages should result >> in Unable-to-Comply >> >> Use case – agent throttling when client supports DOIC unable-to-comply >> also works >> >> Use case – Server throttling – too-busy works >> >> Could add optional “error-diagnostic AVP†to indicate the reason for >> unable-to-comply – should be addressed in a separate RFC >> >> -- >> -------------------------------------+------------------------------------- >> Reporter: | Owner: draft-ietf-dime- >> srdonovan@usdonovans.com | ovli@tools.ietf.org >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: draft-ietf-dime-ovli | Version: >> Severity: Active WG Document | Resolution: >> Keywords: | >> -------------------------------------+------------------------------------- >> >> Ticket URL: >> dime >> > From nobody Mon Oct 20 10:12:03 2014 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 C3C351A887C for ; Mon, 20 Oct 2014 10:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 q-mTMUDk3dgL for ; Mon, 20 Oct 2014 10:12:00 -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 D64D61A88DE for ; Mon, 20 Oct 2014 10:01:08 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:53112 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgGKN-000BA1-TM; Mon, 20 Oct 2014 10:01:07 -0700 Message-ID: <54453FCE.40308@usdonovans.com> Date: Mon, 20 Oct 2014 19:01:02 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell , dime@ietf.org References: <057.235f5e0676a095cce4d25acf9f348309@trac.tools.ietf.org> <072.365b5b87086f75644c491e8483853849@trac.tools.ietf.org> <8BAFA865-71FD-4020-993F-DF21005CD73B@nostrum.com> In-Reply-To: <8BAFA865-71FD-4020-993F-DF21005CD73B@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/E5cUJxpxrCGxP2bEX0qYdJY7K14 Cc: draft-ietf-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #66 (draft-ietf-dime-ovli): Non-Supporting Agent Changing Origin-Host 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, 20 Oct 2014 17:12:01 -0000 That is something we talked about. I'll add it to the deployment considerations section if there are no objections. Steve On 10/20/14, 4:07 PM, Ben Campbell wrote: > I thought we were going to distinguish between DOIC supporting and non-supporting proxies. Specifically, a DOIC supporting proxy that performs topology hiding needs to ensure that any OLRs are appropriate in the context of the answer in which they are sent. > >> On Oct 20, 2014, at 6:54 AM, dime issue tracker wrote: >> >> #66: Non-Supporting Agent Changing Origin-Host >> >> Changes (by srdonovan@usdonovans.com): >> >> * status: new => closed >> * resolution: => fixed >> >> >> Comment: >> >> Agreed that the behavior of Topology Hiding agents/proxies is out of scope >> for this document. >> >> Added appendix on deployment consideration with the following wording: >> >> Topology hiding interactions >> >> There exist proxies that implement what is refered to as Topology >> Hiding. This can include cases where the agent modifies the >> Origin-Host in answer messages. The behavior of the DOIC solution >> is not well understood when this happens. As such, the DOIC >> solution does not address this scenario. >> >> -- >> -------------------------+------------------------------------------------- >> Reporter: | Owner: draft-ietf-dime- >> ben@nostrum.com | ovli@tools.ietf.org >> Type: defect | Status: closed >> Priority: major | Milestone: >> Component: draft-ietf- | Version: 2.0 >> dime-ovli | Resolution: fixed >> Severity: Active WG | >> Document | >> Keywords: | >> -------------------------+------------------------------------------------- >> >> Ticket URL: >> dime >> > From nobody Mon Oct 20 10:13:26 2014 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 6CF4F1A889F for ; Mon, 20 Oct 2014 10:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aYim3eyKtU-J for ; Mon, 20 Oct 2014 10:13:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 639B21A8900 for ; Mon, 20 Oct 2014 10:02:04 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9KH22q7092626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 12:02:03 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <54453F6B.1070502@usdonovans.com> Date: Mon, 20 Oct 2014 12:02:02 -0500 X-Mao-Original-Outgoing-Id: 435517322.666406-95f090c6f09061c43976f81b2c1e7af1 Content-Transfer-Encoding: quoted-printable Message-Id: <5A1EF972-C8C8-405E-8FD4-8E75C3E6FF61@nostrum.com> References: <066.8ce734c1c66c770a886774c6bf72f7be@trac.tools.ietf.org> <081.59481ca83ddcf9ab4a68dda3859e21ec@trac.tools.ietf.org> <7351BCD3-8FF0-4485-9110-66C3C07CBB06@nostrum.com> <54453F6B.1070502@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/uk6-gb9Sb52eu8DUv5tJrFmOiq0 Cc: dime@ietf.org, draft-ietf-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #85 (draft-ietf-dime-ovli): New error response 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, 20 Oct 2014 17:13:09 -0000 Not really. I will respond to that email separately. > On Oct 20, 2014, at 11:59 AM, Steve Donovan = wrote: >=20 > Ben, >=20 > I attempted to treat them generically in the separate email I sent = with the title "[Dime] Proposal for error response wording (issue 85)". >=20 > Does that address your concern? >=20 > Steve >=20 > On 10/20/14, 4:18 PM, Ben Campbell wrote: >> I think the guidance of agents sending unable-to-comply and servers = sending too-busy needs to be pointed out as "typical". There may be = cases where the opposites make sense, e.g., if an agent has reason to = think an alternate route may be ok (as in agent-overload), it might send = too-busy. If a server has reason to believe that the request should not = be retried, it can send unable-to-comply. >>=20 >> It's probably best to state this generically based on the expected = result (retrying on different route vs final error.), and then describe = "typical" behavior for agents and servers. >>=20 >>> On Oct 20, 2014, at 1:38 AM, dime issue tracker = wrote: >>>=20 >>> #85: New error response >>>=20 >>>=20 >>> Comment (by srdonovan@usdonovans.com): >>>=20 >>> Raw notes taken from discussion at interim meeting: >>>=20 >>> Requirements >>>=20 >>> =E2=80=A2 Current Too-Busy behavior allows for retry >>> =E2=80=A2 Too-Busy was originally defined to have a per = connection scope >>> =E2=80=A2 MUST only be used when a specific server exists >>> o This might mean that Too-Busy cannot be used for the = throttle >>> error without updating the definition of Too-Busy behavior >>> =E2=80=A2 Unable-to-deliver might be another alternative for = throttling >>> behavior >>>=20 >>> =E2=80=A2 Need new error response behavior =E2=80=93 DOIC = needs error response >>> behavior to prevent retries due to the message being throttled. >>>=20 >>> =E2=80=A2 Need to handle case where transaction client = supports the >>> throttling error behavior and for transaction clients that do not = support >>> the throttling error behavior. >>>=20 >>> Proposal: Use Unable-to-Comply error code when throttling by agent, = too- >>> busy when throttling by server >>>=20 >>> Use case where agent is reacting node =E2=80=93 throttled messages = should result >>> in Unable-to-Comply >>>=20 >>> Use case =E2=80=93 agent throttling when client supports DOIC = unable-to-comply >>> also works >>>=20 >>> Use case =E2=80=93 Server throttling =E2=80=93 too-busy works >>>=20 >>> Could add optional =E2=80=9Cerror-diagnostic AVP=E2=80=9D to = indicate the reason for >>> unable-to-comply =E2=80=93 should be addressed in a separate RFC >>>=20 >>> --=20 >>> = -------------------------------------+------------------------------------= - >>> Reporter: | Owner: draft-ietf-dime- >>> srdonovan@usdonovans.com | ovli@tools.ietf.org >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: draft-ietf-dime-ovli | Version: >>> Severity: Active WG Document | Resolution: >>> Keywords: | >>> = -------------------------------------+------------------------------------= - >>>=20 >>> Ticket URL: = >>> dime >>>=20 >>=20 >=20 From nobody Mon Oct 20 10:18:08 2014 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 C84DF1A87AF for ; Mon, 20 Oct 2014 10:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nLaStzCWAXtf for ; Mon, 20 Oct 2014 10:18:04 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 877381A0A6A for ; Mon, 20 Oct 2014 10:10:19 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9KHAIsP093372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 12:10:19 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <5444E8B9.8090002@usdonovans.com> Date: Mon, 20 Oct 2014 12:10:17 -0500 X-Mao-Original-Outgoing-Id: 435517817.935341-8eb009c7aa22317cdffcb233e25bc0f4 Content-Transfer-Encoding: quoted-printable Message-Id: <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> References: <5444E8B9.8090002@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qL2ds2wxJmTKr56tIF29G4vyT88 Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for error response wording (issue 85) 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, 20 Oct 2014 17:18:06 -0000 I agree that we should generalize these, but I think the direction is = not quite right. More inline: > On Oct 20, 2014, at 5:49 AM, Steve Donovan = wrote: >=20 > We came to the following agreements on error responses: >=20 > - Servers rejecting a Diameter request due to an overload condition = should send a 3002 DIAMETER_TOO_BUSY error response. >=20 > - Agents rejecting a Diameter request due to an overload condition = should send a 5012 DIAMETER_UNABLE_TO_COMPLY. >=20 > I propose that we generalize this to the following: >=20 > - Reporting nodes rejecting a Diameter request due to an overload = condition SHOULD send a 3002 DIAMETER-TOO-BUSY error response. >=20 > - Reacting nodes rejecting a Diameter request due to an overload = condition SHOULD send a UNABLE-TO-COMPLY. I don't think we should state this in terms of reaction and reporting = nodes. I think we should generalize to expected behavior. Also, in the = case where the downstream node does not support DOIC, I'm not sure it = makes sense to say the throttling node is really a reporting node (for = that particular relationship.) My suggestion is we say that, if the throttling node has sufficient = information to determine that the request is not likely to succeed if = retried on another path, it SHOULD send UNABLE-TO-COMPLY. If it does not = have that information, it SHOULD send TOO-BUSY. (we should discuss why = this is not a MUST if we have the conditionals in place.) Then we could go on to say that a reaction node (or agent) would = typically fall under the first category, and a reporting node (or = server) would typically fall under the second. But there certainly may = be cases where a reacting node does not know if other paths could work, = and where a reporting node might know that they couldn't.=20 >=20 > This would mean that an agent acting as a reporting node (i.e.; server = doesn't support DOIC or agent is acting as a server front end) would = sent the TOO_BUSY response and an agent acting as a reacting node (i.e.; = a client doesn't support DOIC) then it sends a UNABLE_TO_COMPLY = response. >=20 > I propose adding this to a new section 4.2.4. The existing 4.2.4 on = agent behavior will be deleted. >=20 > I will hold off making this change until tomorrow (Tuesday morning). >=20 > Regards, >=20 > Steve >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Mon Oct 20 12:57:17 2014 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 D222E1ACD73 for ; Mon, 20 Oct 2014 12:57:15 -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, HTML_MESSAGE=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 SOKA58Bi48oW for ; Mon, 20 Oct 2014 12:57:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E142B1ACD6A for ; Mon, 20 Oct 2014 12:57:13 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9KJvCJm008892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 14:57:13 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: Ben Campbell Content-Type: multipart/alternative; boundary="Apple-Mail=_57E684A6-AE27-435E-B00D-3B4D1A7D0803" X-Mao-Original-Outgoing-Id: 435527831.921899-8d0464e57181478c678dc6a645e83daf Message-Id: <7A2FFE7D-41BB-43E8-95E2-7B63FC7E6A46@nostrum.com> Date: Mon, 20 Oct 2014 14:57:11 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) To: "dime@ietf.org list" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pFoZ9nZ1POFVwi3KEkBEQBF4Hgw Subject: [Dime] Proposed Text for Issue 43 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, 20 Oct 2014 19:57:16 -0000 --Apple-Mail=_57E684A6-AE27-435E-B00D-3B4D1A7D0803 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Steve reminded me I owned some text on issue 43. The existing text has = moved to 3.6.4 in 04, but I think it stayed the same. Here are some = proposed updates: Thanks! Ben. -------------------- general:=20 Section headings (even unnumbered ones) should be in title case. Colon = missing from =E2=80=9CIntra-Session Request=E2=80=9D heading. Independent Request Section: Old: Independent requests can be given equal treatment when making throttling = decisions. New: Independent requests can generally be given equal treatment when making = throttling decisions, unless otherwise indicated by application = requirements or local policy. Session-Initiating Requests: Old: Session-initiating requests represent more work than independent or = intra-session requests. Moreover, session-initiating requests are = typically followed by other session-related requests. As such, as the = main objective of the overload control is to reduce the total number of = requests sent to the overloaded entity, throttling decisions might favor = allowing intra-session requests over session-initiating requests. = Individual session-initiating requests can be given equal treatment when = making throttling decisions. New: Session-initiating requests often represent more work than independent = or intra-session requests. Moreover, session-initiating requests are = typically followed by other session-related requests. Since the main = objective of the overload control is to reduce the total number of = requests sent to the overloaded entity, throttling decisions might favor = allowing intra-session requests over session-initiating requests. In = the absence of local policies or application specific requirements to = the contrary, Individual session-initiating requests can be given equal = treatment when making throttling decisions. Correlated Session-Initiationg Requests and Pseudo-session requests = sections: [Existing text is fine as is] Intra-Session Requests: Old: There are two classes of intra-sessions requests. The first class = consists of requests that terminate a session. The second one contains = the set of requests that are used by the Diameter client and server to = maintain the ongoing session state. Session terminating requests should = be throttled less aggressively in order to gracefully terminate = sessions, allow clean-up of the related resources (e.g. session state) = and get rid of the need for other intra-session requests, reducing the = session management impact on the overloaded entity. The default = handling of other intra-session requests might be to treat them equally = when making throttling decisions. There might also be application level = considerations whether some request types are favored over others. New: There are two classes of intra-sessions requests. The first class = consists of requests that terminate a session. The second class = comprises requests that are used by the Diameter client and server to = maintain the ongoing session state. Implementors and operators may = choose to throttle session-terminating requests less aggressively in = order to gracefully terminate sessions, allow clean-up of the related = resources (e.g. session state) and avoid the need for additional = intra-session requests. Favoring session-termination requests may reduce = the session management impact on the overloaded entity. The default = handling of other intra-session requests might be to treat them equally = when making throttling decisions. There might also be application level = considerations whether some request types are favored over others. --Apple-Mail=_57E684A6-AE27-435E-B00D-3B4D1A7D0803 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Steve reminded me I owned some text on issue 43. The existing = text has moved to 3.6.4 in 04, but I think it stayed the same. Here are = some proposed updates:

Thanks!

Ben.

--------------------

general: 

Section headings (even = unnumbered ones) should be in title case. Colon missing from = =E2=80=9CIntra-Session Request=E2=80=9D heading.


Independent Request Section:

Old:

Independent requests can be = given equal treatment when making throttling = decisions.

New:

Independent requests can generally be given equal treatment = when making throttling decisions, unless otherwise indicated by = application requirements or local policy.

Session-Initiating Requests:

Old:

Session-initiating= requests represent more work than independent or intra-session = requests.  Moreover, session-initiating requests are typically = followed by other session-related requests.  As such, as the main = objective of the overload control is to reduce the total number of = requests sent to the overloaded entity, throttling decisions might favor = allowing intra-session requests over session-initiating requests. =  Individual session-initiating requests can be given equal = treatment when making throttling decisions.

New:

Session-initiating = requests often represent more work than independent or intra-session = requests.  Moreover, session-initiating requests are typically = followed by other session-related requests.  Since the main = objective of the overload control is to reduce the total number of = requests sent to the overloaded entity, throttling decisions might favor = allowing intra-session requests over session-initiating requests. =  In the absence of local policies or application specific = requirements to the contrary, Individual session-initiating requests can = be given equal treatment when making throttling = decisions.

Correlated Session-Initiationg Requests and = Pseudo-session requests sections:

[Existing text is fine as = is]

Intra-Session Requests:

Old:

There are two classes of = intra-sessions requests.  The first class consists of requests that = terminate a session.  The second one contains the set of requests = that are used by the Diameter client and server to maintain the ongoing = session state.  Session terminating requests should be throttled = less aggressively in order to gracefully terminate sessions, allow = clean-up of the related resources (e.g. session state) and get rid of = the need for other intra-session requests, reducing the session = management impact on the overloaded entity.  The default handling = of other intra-session requests might be to treat them equally when = making throttling decisions.  There might also be application level = considerations whether some request types are favored over = others.

New:
There are two = classes of intra-sessions requests.  The first class consists of = requests that terminate a session.  The second class comprises = requests that are used by the Diameter client and server to maintain the = ongoing session state.  Implementors and operators may choose to = throttle session-terminating requests less aggressively in order to = gracefully terminate sessions, allow clean-up of the related resources = (e.g. session state) and avoid the need for additional intra-session = requests. Favoring session-termination requests may reduce the session = management impact on the overloaded entity.  The default handling = of other intra-session requests might be to treat them equally when = making throttling decisions.  There might also be application level = considerations whether some request types are favored over = others.







= --Apple-Mail=_57E684A6-AE27-435E-B00D-3B4D1A7D0803-- From nobody Mon Oct 20 14:17:08 2014 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 D14EC1ACEE0 for ; Mon, 20 Oct 2014 14:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J5QPvRZFoUBX for ; Mon, 20 Oct 2014 14:17:04 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3694D1ACEDB for ; Mon, 20 Oct 2014 14:17:04 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9KLH2FD015947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 16:17:03 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <5444D8F9.9040906@usdonovans.com> Date: Mon, 20 Oct 2014 16:17:02 -0500 X-Mao-Original-Outgoing-Id: 435532622.221494-1d40a600f00122b9ee729e1590b213c4 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5444D8F9.9040906@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/yDDxsPUC28F0Ff8mC878Qz0dVqo Cc: "dime@ietf.org" Subject: Re: [Dime] Resolution to issues 70 and 74 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, 20 Oct 2014 21:17:06 -0000 Slight normative language quibble: "MUST only" is a bit of a strange construction from a 2119 perspective, = in that it implies a negation without an explicit NOT. I think we really = mean "MUST NOT unless...". > On Oct 20, 2014, at 4:42 AM, Steve Donovan = wrote: >=20 > I have removed the examples section and moved the "Application = Considerations" section to an appendix. >=20 > For issue 70 I also added the following wording to section 4.2.3: >=20 > A reporting node MUST only send overload reports of a type = advertised > as supported by the reacting node. >=20 > Note that a reacting node advertises support for the host and > realm report types by including the OC-Supported-Features AVP in > the request. Support for other report types must be explicitly > indicated by a new feature bit in the OC-Feature-Vector AVP. >=20 >=20 >=20 > The diff file is attached. >=20 > Regards, >=20 > Steve > _________________________________________= ______ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Mon Oct 20 14:41:11 2014 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 31F4A1ACF0A for ; Mon, 20 Oct 2014 14:41:10 -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 ivV4-L6U2Hyf for ; Mon, 20 Oct 2014 14:41:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF391ACF06 for ; Mon, 20 Oct 2014 14:41:07 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 17BBD3B42DC; Mon, 20 Oct 2014 23:41:06 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id E1038158078; Mon, 20 Oct 2014 23:41:05 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 23:41:05 +0200 From: To: Ben Campbell , Steve Donovan Thread-Topic: [Dime] Proposal for error response wording (issue 85) Thread-Index: AQHP7FOMzo+IEEAdVEGPqLkd/UJbyJw5F0KAgABpp+A= Date: Mon, 20 Oct 2014 21:41:05 +0000 Message-ID: <22114_1413841265_54458171_22114_4224_1_6B7134B31289DC4FAF731D844122B36E8005B4@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <5444E8B9.8090002@usdonovans.com> <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> In-Reply-To: <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.20.200325 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/znyy42TCc2pGNLXh21jjp4x82lw Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for error response wording (issue 85) 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, 20 Oct 2014 21:41:10 -0000 Hi, I think that: - TOO_BUSY should be restricted to server answer - UNABLE_TO_COMPLY as answer to non-supporting DOIC when no retransmission = is required - UNABLE_TO_DELIVER to supporting DOIC and to non-supporting DOIC node when= retransmission to an alternate peer could be better. As a second step, we could enhance the answer message (in this draft or in = a separate draft if preferred) with an error message (e.g. "Error-Diagnosti= c") that could provide further information to "new" node that will be then = able to adapt their behavior. So a supporting DOIC receiving UNABLE_TO_DELIVER/TOO_BUSY with an Error-Dia= gnostic set to e.g. "severe overload", besides the OLR in the answer, will = know that retransmission on the path or a on a different path will likely c= ause the same error. If no error-diagnostic is sent back or ignored by the = non-supporting-DOOIC node, we will go back to the situation prior this draf= t. Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9=A0: lundi 20 octobre 2014 19:10 =C0=A0: Steve Donovan Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Proposal for error response wording (issue 85) I agree that we should generalize these, but I think the direction is not q= uite right. More inline: > On Oct 20, 2014, at 5:49 AM, Steve Donovan wro= te: >=20 > We came to the following agreements on error responses: >=20 > - Servers rejecting a Diameter request due to an overload condition shoul= d send a 3002 DIAMETER_TOO_BUSY error response. >=20 > - Agents rejecting a Diameter request due to an overload condition should= send a 5012 DIAMETER_UNABLE_TO_COMPLY. >=20 > I propose that we generalize this to the following: >=20 > - Reporting nodes rejecting a Diameter request due to an overload conditi= on SHOULD send a 3002 DIAMETER-TOO-BUSY error response. >=20 > - Reacting nodes rejecting a Diameter request due to an overload conditio= n SHOULD send a UNABLE-TO-COMPLY. I don't think we should state this in terms of reaction and reporting nodes= . I think we should generalize to expected behavior. Also, in the case wher= e the downstream node does not support DOIC, I'm not sure it makes sense to= say the throttling node is really a reporting node (for that particular re= lationship.) My suggestion is we say that, if the throttling node has sufficient informa= tion to determine that the request is not likely to succeed if retried on a= nother path, it SHOULD send UNABLE-TO-COMPLY. If it does not have that info= rmation, it SHOULD send TOO-BUSY. (we should discuss why this is not a MU= ST if we have the conditionals in place.) Then we could go on to say that a reaction node (or agent) would typically = fall under the first category, and a reporting node (or server) would typic= ally fall under the second. But there certainly may be cases where a reacti= ng node does not know if other paths could work, and where a reporting node= might know that they couldn't.=20 >=20 > This would mean that an agent acting as a reporting node (i.e.; server do= esn't support DOIC or agent is acting as a server front end) would sent the= TOO_BUSY response and an agent acting as a reacting node (i.e.; a client d= oesn't support DOIC) then it sends a UNABLE_TO_COMPLY response. >=20 > I propose adding this to a new section 4.2.4. The existing 4.2.4 on agen= t behavior will be deleted. >=20 > I will hold off making this change until tomorrow (Tuesday morning). >=20 > Regards, >=20 > Steve >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, 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 Mon Oct 20 15:21:29 2014 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 499F91ACF03 for ; Mon, 20 Oct 2014 15:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YMykDdLRZdtb for ; Mon, 20 Oct 2014 15:21:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A84E91ACEFE for ; Mon, 20 Oct 2014 15:21:22 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9KMLLj6022210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 17:21:22 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <22114_1413841265_54458171_22114_4224_1_6B7134B31289DC4FAF731D844122B36E8005B4@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Mon, 20 Oct 2014 17:21:20 -0500 X-Mao-Original-Outgoing-Id: 435536480.243884-110da8b2cab79789e2c4a995d473dc99 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5444E8B9.8090002@usdonovans.com> <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> <22114_1413841265_54458171_22114_4224_1_6B7134B31289DC4FAF731D844122B36E8005B4@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tKaVTSOqGti0hDzGCoVuhsshEhg Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for error response wording (issue 85) 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, 20 Oct 2014 22:21:26 -0000 > On Oct 20, 2014, at 4:41 PM, = wrote: >=20 > Hi, >=20 > I think that: > - TOO_BUSY should be restricted to server answer One of the reasons I think we need to state this by intended result and = not by role in the network, is that I expect that an overloaded agent = (according to the agent overload draft) might send TOO-BUSY. And a = server that acts as an overload authority for a realm might send = UNABLE-TO-[COMPLY or DELIVER] to a request that did not contain a = Destination-Host AVP. > - UNABLE_TO_COMPLY as answer to non-supporting DOIC when no = retransmission is required > - UNABLE_TO_DELIVER to supporting DOIC and to non-supporting DOIC node = when retransmission to an alternate peer could be better. >=20 > As a second step, we could enhance the answer message (in this draft = or in a separate draft if preferred) with an error message (e.g. = "Error-Diagnostic") that could provide further information to "new" node = that will be then able to adapt their behavior. > So a supporting DOIC receiving UNABLE_TO_DELIVER/TOO_BUSY with an = Error-Diagnostic set to e.g. "severe overload", besides the OLR in the = answer, will know that retransmission on the path or a on a different = path will likely cause the same error. If no error-diagnostic is sent = back or ignored by the non-supporting-DOOIC node, we will go back to the = situation prior this draft. >=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell > Envoy=E9 : lundi 20 octobre 2014 19:10 > =C0 : Steve Donovan > Cc : dime@ietf.org > Objet : Re: [Dime] Proposal for error response wording (issue 85) >=20 > I agree that we should generalize these, but I think the direction is = not quite right. More inline: >=20 >> On Oct 20, 2014, at 5:49 AM, Steve Donovan = wrote: >>=20 >> We came to the following agreements on error responses: >>=20 >> - Servers rejecting a Diameter request due to an overload condition = should send a 3002 DIAMETER_TOO_BUSY error response. >>=20 >> - Agents rejecting a Diameter request due to an overload condition = should send a 5012 DIAMETER_UNABLE_TO_COMPLY. >>=20 >> I propose that we generalize this to the following: >>=20 >> - Reporting nodes rejecting a Diameter request due to an overload = condition SHOULD send a 3002 DIAMETER-TOO-BUSY error response. >>=20 >> - Reacting nodes rejecting a Diameter request due to an overload = condition SHOULD send a UNABLE-TO-COMPLY. >=20 > I don't think we should state this in terms of reaction and reporting = nodes. I think we should generalize to expected behavior. Also, in the = case where the downstream node does not support DOIC, I'm not sure it = makes sense to say the throttling node is really a reporting node (for = that particular relationship.) >=20 > My suggestion is we say that, if the throttling node has sufficient = information to determine that the request is not likely to succeed if = retried on another path, it SHOULD send UNABLE-TO-COMPLY. If it does not = have that information, it SHOULD send TOO-BUSY. (we should discuss why = this is not a MUST if we have the conditionals in place.) >=20 > Then we could go on to say that a reaction node (or agent) would = typically fall under the first category, and a reporting node (or = server) would typically fall under the second. But there certainly may = be cases where a reacting node does not know if other paths could work, = and where a reporting node might know that they couldn't.=20 >=20 >=20 >>=20 >> This would mean that an agent acting as a reporting node (i.e.; = server doesn't support DOIC or agent is acting as a server front end) = would sent the TOO_BUSY response and an agent acting as a reacting node = (i.e.; a client doesn't support DOIC) then it sends a UNABLE_TO_COMPLY = response. >>=20 >> I propose adding this to a new section 4.2.4. The existing 4.2.4 on = agent behavior will be deleted. >>=20 >> I will hold off making this change until tomorrow (Tuesday morning). >>=20 >> Regards, >>=20 >> Steve >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > 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 From nobody Mon Oct 20 21:53:23 2014 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 723EA1AD042 for ; Mon, 20 Oct 2014 21:53:22 -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 MrtUpxhtDEmv for ; Mon, 20 Oct 2014 21:53:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F541AD035 for ; Mon, 20 Oct 2014 21:53:19 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 8B2643B450C; Tue, 21 Oct 2014 06:53:17 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 70A7E180051; Tue, 21 Oct 2014 06:53:17 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 06:53:17 +0200 From: To: Ben Campbell Thread-Topic: [Dime] Proposal for error response wording (issue 85) Thread-Index: AQHP7FOMzo+IEEAdVEGPqLkd/UJbyJw5F0KAgABpp+D//+1BAIAAjwka Date: Tue, 21 Oct 2014 04:53:16 +0000 Message-ID: <1979_1413867197_5445E6BD_1979_10335_1_s8e3rg7h7yyc2r23mds3uefp.1413867190363@email.android.com> References: <5444E8B9.8090002@usdonovans.com> <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> <22114_1413841265_54458171_22114_4224_1_6B7134B31289DC4FAF731D844122B36E8005B4@PEXCVZYM13.corporate.adroot.infra.ftgroup>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.20.221821 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/WWBsN8PsmZD3lDEXfNe48ehS-mY Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for error response wording (issue 85) 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, 21 Oct 2014 04:53:22 -0000 I agree. Lionel Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Ben Campbell a =E9crit ---- > On Oct 20, 2014, at 4:41 PM, wrote: > > Hi, > > I think that: > - TOO_BUSY should be restricted to server answer One of the reasons I think we need to state this by intended result and not= by role in the network, is that I expect that an overloaded agent (accordi= ng to the agent overload draft) might send TOO-BUSY. And a server that acts= as an overload authority for a realm might send UNABLE-TO-[COMPLY or DELIV= ER] to a request that did not contain a Destination-Host AVP. > - UNABLE_TO_COMPLY as answer to non-supporting DOIC when no retransmissio= n is required > - UNABLE_TO_DELIVER to supporting DOIC and to non-supporting DOIC node wh= en retransmission to an alternate peer could be better. > > As a second step, we could enhance the answer message (in this draft or i= n a separate draft if preferred) with an error message (e.g. "Error-Diagnos= tic") that could provide further information to "new" node that will be the= n able to adapt their behavior. > So a supporting DOIC receiving UNABLE_TO_DELIVER/TOO_BUSY with an Error-D= iagnostic set to e.g. "severe overload", besides the OLR in the answer, wil= l know that retransmission on the path or a on a different path will likely= cause the same error. If no error-diagnostic is sent back or ignored by th= e non-supporting-DOOIC node, we will go back to the situation prior this dr= aft. > > Regards, > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell > Envoy=E9 : lundi 20 octobre 2014 19:10 > =C0 : Steve Donovan > Cc : dime@ietf.org > Objet : Re: [Dime] Proposal for error response wording (issue 85) > > I agree that we should generalize these, but I think the direction is not= quite right. More inline: > >> On Oct 20, 2014, at 5:49 AM, Steve Donovan wr= ote: >> >> We came to the following agreements on error responses: >> >> - Servers rejecting a Diameter request due to an overload condition shou= ld send a 3002 DIAMETER_TOO_BUSY error response. >> >> - Agents rejecting a Diameter request due to an overload condition shoul= d send a 5012 DIAMETER_UNABLE_TO_COMPLY. >> >> I propose that we generalize this to the following: >> >> - Reporting nodes rejecting a Diameter request due to an overload condit= ion SHOULD send a 3002 DIAMETER-TOO-BUSY error response. >> >> - Reacting nodes rejecting a Diameter request due to an overload conditi= on SHOULD send a UNABLE-TO-COMPLY. > > I don't think we should state this in terms of reaction and reporting nod= es. I think we should generalize to expected behavior. Also, in the case wh= ere the downstream node does not support DOIC, I'm not sure it makes sense = to say the throttling node is really a reporting node (for that particular = relationship.) > > My suggestion is we say that, if the throttling node has sufficient infor= mation to determine that the request is not likely to succeed if retried on= another path, it SHOULD send UNABLE-TO-COMPLY. If it does not have that in= formation, it SHOULD send TOO-BUSY. (we should discuss why this is not a = MUST if we have the conditionals in place.) > > Then we could go on to say that a reaction node (or agent) would typicall= y fall under the first category, and a reporting node (or server) would typ= ically fall under the second. But there certainly may be cases where a reac= ting node does not know if other paths could work, and where a reporting no= de might know that they couldn't. > > >> >> This would mean that an agent acting as a reporting node (i.e.; server d= oesn't support DOIC or agent is acting as a server front end) would sent th= e TOO_BUSY response and an agent acting as a reacting node (i.e.; a client = doesn't support DOIC) then it sends a UNABLE_TO_COMPLY response. >> >> I propose adding this to a new section 4.2.4. The existing 4.2.4 on age= nt behavior will be deleted. >> >> I will hold off making this change until tomorrow (Tuesday morning). >> >> Regards, >> >> Steve >> >> _______________________________________________ >> 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 confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n 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. From nobody Tue Oct 21 00:04:22 2014 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 0FB281AD09A for ; Tue, 21 Oct 2014 00:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6Zg6JuV8cKcW for ; Tue, 21 Oct 2014 00:04:19 -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 1FC6D1AD08F for ; Tue, 21 Oct 2014 00:04:19 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:54838 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgTUI-000Bhh-Cj; Tue, 21 Oct 2014 00:04:16 -0700 Message-ID: <54460567.4020400@usdonovans.com> Date: Tue, 21 Oct 2014 09:04:07 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, Ben Campbell References: <5444E8B9.8090002@usdonovans.com> <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> <22114_1413841265_54458171_22114_4224_1_6B7134B31289DC4FAF731D844122B36E8005B4@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <1979_1413867197_5445E6BD_1979_10335_1_s8e3rg7h7yyc2r23mds3uefp.1413867190363@email.android.com> In-Reply-To: <1979_1413867197_5445E6BD_1979_10335_1_s8e3rg7h7yyc2r23mds3uefp.1413867190363@email.android.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qGEwI8UEbJKZDVN1-f5WtRpvOGg Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for error response wording (issue 85) 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, 21 Oct 2014 07:04:21 -0000 I'll work Ben's suggestion into the draft. I expect it to go into the existing Error Response section. I don't think we have time to define an error-diagnostic AVP. Steve On 10/21/14, 6:53 AM, lionel.morand@orange.com wrote: > I agree. > > Lionel > > Envoyé depuis mon Sony Xperia SP d'Orange > > ---- Ben Campbell a écrit ---- > > >> On Oct 20, 2014, at 4:41 PM, wrote: >> >> Hi, >> >> I think that: >> - TOO_BUSY should be restricted to server answer > One of the reasons I think we need to state this by intended result and not by role in the network, is that I expect that an overloaded agent (according to the agent overload draft) might send TOO-BUSY. And a server that acts as an overload authority for a realm might send UNABLE-TO-[COMPLY or DELIVER] to a request that did not contain a Destination-Host AVP. > >> - UNABLE_TO_COMPLY as answer to non-supporting DOIC when no retransmission is required >> - UNABLE_TO_DELIVER to supporting DOIC and to non-supporting DOIC node when retransmission to an alternate peer could be better. >> >> As a second step, we could enhance the answer message (in this draft or in a separate draft if preferred) with an error message (e.g. "Error-Diagnostic") that could provide further information to "new" node that will be then able to adapt their behavior. >> So a supporting DOIC receiving UNABLE_TO_DELIVER/TOO_BUSY with an Error-Diagnostic set to e.g. "severe overload", besides the OLR in the answer, will know that retransmission on the path or a on a different path will likely cause the same error. If no error-diagnostic is sent back or ignored by the non-supporting-DOOIC node, we will go back to the situation prior this draft. >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell >> Envoyé : lundi 20 octobre 2014 19:10 >> À : Steve Donovan >> Cc : dime@ietf.org >> Objet : Re: [Dime] Proposal for error response wording (issue 85) >> >> I agree that we should generalize these, but I think the direction is not quite right. More inline: >> >>> On Oct 20, 2014, at 5:49 AM, Steve Donovan wrote: >>> >>> We came to the following agreements on error responses: >>> >>> - Servers rejecting a Diameter request due to an overload condition should send a 3002 DIAMETER_TOO_BUSY error response. >>> >>> - Agents rejecting a Diameter request due to an overload condition should send a 5012 DIAMETER_UNABLE_TO_COMPLY. >>> >>> I propose that we generalize this to the following: >>> >>> - Reporting nodes rejecting a Diameter request due to an overload condition SHOULD send a 3002 DIAMETER-TOO-BUSY error response. >>> >>> - Reacting nodes rejecting a Diameter request due to an overload condition SHOULD send a UNABLE-TO-COMPLY. >> I don't think we should state this in terms of reaction and reporting nodes. I think we should generalize to expected behavior. Also, in the case where the downstream node does not support DOIC, I'm not sure it makes sense to say the throttling node is really a reporting node (for that particular relationship.) >> >> My suggestion is we say that, if the throttling node has sufficient information to determine that the request is not likely to succeed if retried on another path, it SHOULD send UNABLE-TO-COMPLY. If it does not have that information, it SHOULD send TOO-BUSY. (we should discuss why this is not a MUST if we have the conditionals in place.) >> >> Then we could go on to say that a reaction node (or agent) would typically fall under the first category, and a reporting node (or server) would typically fall under the second. But there certainly may be cases where a reacting node does not know if other paths could work, and where a reporting node might know that they couldn't. >> >> >>> This would mean that an agent acting as a reporting node (i.e.; server doesn't support DOIC or agent is acting as a server front end) would sent the TOO_BUSY response and an agent acting as a reacting node (i.e.; a client doesn't support DOIC) then it sends a UNABLE_TO_COMPLY response. >>> >>> I propose adding this to a new section 4.2.4. The existing 4.2.4 on agent behavior will be deleted. >>> >>> I will hold off making this change until tomorrow (Tuesday morning). >>> >>> Regards, >>> >>> Steve >>> >>> _______________________________________________ >>> 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. > > From nobody Tue Oct 21 00:06:45 2014 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 9B13E1A8033 for ; Mon, 20 Oct 2014 05:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 4UnudHSQrROK for ; Mon, 20 Oct 2014 05:18:02 -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 6C8B51A701C for ; Mon, 20 Oct 2014 05:18:02 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:51612 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgBuS-0000Pk-5y for dime@ietf.org; Mon, 20 Oct 2014 05:18:01 -0700 Message-ID: <5444FD77.6000602@usdonovans.com> Date: Mon, 20 Oct 2014 14:17:59 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------060304030807010104050902" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Py0yUCaY7UFGcQpMh5ra9cFWfKk X-Mailman-Approved-At: Tue, 21 Oct 2014 00:06:24 -0700 Subject: [Dime] Resolution to issue 67 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, 20 Oct 2014 12:18:05 -0000 X-List-Received-Date: Mon, 20 Oct 2014 12:18:05 -0000 This is a multi-part message in MIME format. --------------060304030807010104050902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have updated github with the resolution to issue 67. The diff is attached. Regards, Steve --------------060304030807010104050902 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 2, line 28 skipping to change at page 2, line 28
3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7
3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 8 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 8
3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10
3.5. Simplified Example Architecture . . . . . . . . . . . . . 10 3.5. Simplified Example Architecture . . . . . . . . . . . . . 10
4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11
4.1. Capability Announcement . . . . . . . . . . . . . . . . . 11 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 11
4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12
4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12
4.2. Overload Report Processing . . . . . . . . . . . . . . . 13 4.2. Overload Report Processing . . . . . . . . . . . . . . . 13
4.2.1. Overload Control State . . . . . . . . . . . . . . . 13 4.2.1. Overload Control State . . . . . . . . . . . . . . . 13
4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 15
4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17
4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 18 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 18
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 19 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 20 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 20
5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 22 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 22
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 15, line 15 skipping to change at page 15, line 15
such host-type OCS already exists. such host-type OCS already exists.
Reacting nodes create a realm-type OCS identified by OCS-Id = (app- Reacting nodes create a realm-type OCS identified by OCS-Id = (app-
id,realm-id) when receiving an answer message of application app-id id,realm-id) when receiving an answer message of application app-id
containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP
unless such realm type OCS already exists. unless such realm type OCS already exists.
Reacting nodes delete an OCS when it expires (i.e. when current time Reacting nodes delete an OCS when it expires (i.e. when current time
minus reception time is greater than validity duration). minus reception time is greater than validity duration).
Editor's note: Reacting nodes also delete on OCS with an updated OLR Reacting nodes also delete on OCS with an updated OLR is received
is received with a validity duration of zero. with a validity duration of zero.
Reacting nodes update the host-type OCS identified by OCS-Id = (app- Reacting nodes update the host-type OCS identified by OCS-Id = (app-
id,host-id) when receiving an answer message of application app-id id,host-id) when receiving an answer message of application app-id
containing an Orig-Host of host-id and a host-type OC-OLR AVP with a containing an Orig-Host of host-id and a host-type OC-OLR AVP with a
sequence number higher than the stored sequence number. sequence number higher than the stored sequence number.
Reacting nodes update the realm-type OCS identified by OCS-Id = (app- Reacting nodes update the realm-type OCS identified by OCS-Id = (app-
id,realm-id) when receiving an answer message of application app-id id,realm-id) when receiving an answer message of application app-id
containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP with containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP with
a sequence number higher than the stored sequence number. a sequence number higher than the stored sequence number.
skipping to change at page 15, line 40 skipping to change at page 15, line 40
change"). change").
Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg)
when receiving a request of application app-id containing an OC- when receiving a request of application app-id containing an OC-
Supported-Features AVP indicating support of the Abatement Algorithm Supported-Features AVP indicating support of the Abatement Algorithm
Alg (which the reporting node selects) while being overloaded, unless Alg (which the reporting node selects) while being overloaded, unless
such OCS already exists. such OCS already exists.
Reporting nodes delete an OCS when it expires. Reporting nodes delete an OCS when it expires.
Editor's note: Reporting nodes should send updated overload reports
with a validity duration of zero for a period of time after an OCS
expires or is removed due to the overload condition ending.
Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg)
when they detect the need to modify the requested amount of when they detect the need to modify the requested amount of
application app-id traffic reduction. application app-id traffic reduction.
4.2.2. Reacting Node Behavior 4.2.2. Reacting Node Behavior
Once a reacting node receives an OC-OLR AVP from a reporting node, it Once a reacting node receives an OC-OLR AVP from a reporting node, it
applies traffic abatement based on the selected algorithm with the applies traffic abatement based on the selected algorithm with the
reporting node and the current overload condition. The reacting node reporting node and the current overload condition. The reacting node
learns the reporting node supported abatement algorithms directly learns the reporting node supported abatement algorithms directly
skipping to change at page 18, line 45 skipping to change at page 18, line 38
A reporting node MAY rely on the OC-Validity-Duration AVP values for A reporting node MAY rely on the OC-Validity-Duration AVP values for
the implicit overload control state cleanup on the reacting node. the implicit overload control state cleanup on the reacting node.
However, it is RECOMMENDED that the reporting node always explicitly However, it is RECOMMENDED that the reporting node always explicitly
indicates the end of a overload condition. indicates the end of a overload condition.
The reporting node SHOULD indicate the end of an overload occurrence The reporting node SHOULD indicate the end of an overload occurrence
by sending a new OLR with OC-Validity-Duration set to a value of zero by sending a new OLR with OC-Validity-Duration set to a value of zero
("0"). The reporting node SHOULD insure that all reacting nodes ("0"). The reporting node SHOULD insure that all reacting nodes
receive the updated overload report. receive the updated overload report.
All OLRs sent have an expiration time calculated by adding the
validity-duration contained in the OLR to the time the message was
sent. Transit time for the OLR can be safely ignored. The
reporting node can ensure that all reacting nodes have received
the OLR by continuing to send it in answer messages until the
expiration time for all OLRs sent for that overload contition have
expired.
4.3. Protocol Extensibility 4.3. Protocol Extensibility
The overload control solution can be extended, e.g. with new traffic The overload control solution can be extended, e.g. with new traffic
abatement algorithms, new report types or other new functionality. abatement algorithms, new report types or other new functionality.
When defining a new extension a new feature bit MUST be defined for When defining a new extension a new feature bit MUST be defined for
the OC-Feature-Vector. This feature bit is used to communicate the OC-Feature-Vector. This feature bit is used to communicate
support for the new feature. support for the new feature.
The extention may also define new AVPs for use in DOIC Capability The extention may also define new AVPs for use in DOIC Capability
 End of changes. 4 change blocks. 
7 lines changed or deleted 11 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------060304030807010104050902-- From nobody Tue Oct 21 00:06:53 2014 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 D85581A8724 for ; Mon, 20 Oct 2014 09:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 gIM6d8nWnEk1 for ; Mon, 20 Oct 2014 09:39:47 -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 1A73A1A8A96 for ; Mon, 20 Oct 2014 09:27:04 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:53049 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgFnN-0002jZ-DO for dime@ietf.org; Mon, 20 Oct 2014 09:26:58 -0700 Message-ID: <544537CF.7060200@usdonovans.com> Date: Mon, 20 Oct 2014 18:26:55 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------020200010607080807080507" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AIEXWTL8UpA4-WGGLyHmaEDrJ2A X-Mailman-Approved-At: Tue, 21 Oct 2014 00:06:24 -0700 Subject: [Dime] Scrubbing of AVP descriptions, resolution of issue 82 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, 20 Oct 2014 16:39:56 -0000 This is a multi-part message in MIME format. --------------020200010607080807080507 Content-Type: multipart/alternative; boundary="------------020405030206080004040302" --------------020405030206080004040302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit With this update I did a scrub of avp description, removing behavior definitions that are already in other sections. There were also a few editorial changes mixed in. I've attached the diff file and a summary of the changes follows. Regards, Steve ----- Section 6.1 OC-Supported-Features Removed the following which is covered in the section on Capability Announcement: A reacting node includes this AVP to indicate its capabilities to a reporting node. For example, the reacting node may indicate which (future defined) traffic abatement algorithms it supports in addition to the default. During the message exchange the DOIC nodes express their common set of supported capabilities. The reacting node includes the OC- Supported-Features AVP that announces what it supports. The reporting node that sends the answer also includes the OC-Supported- Features AVP that describes the capabilities it supports. The set of capabilities advertised by the reporting node depends on local policies. Since the loss abatement algorithm Section 5 is mandatory to implement DOIC can always be enabled between these DOIC nodes. Also changed the following in section 4.1.1, as the OC-Feature-Vector is an optional parameter: Old text: A reacting node MUST include the OC-Feature-Vector AVP with an indication of the loss algorithm. New text A reacting node MAY include the OC-Feature-Vector AVP with an indication of the loss algorithm. A reacting node MUST include the OC-Feature-Vector AVP to indicate support for abatement algorithms in addition to the loss algorithm. 6.3 OC-OLR Removed the following, it belongs in the OC-Validity-Duration AVP section: The OC-Validity-Duration AVP indicates the validity time of the overload report associated with a specific sequence number, measured after reception of the OC-OLR AVP. The validity time MUST NOT be updated after reception of subsequent OC-OLR AVPs with the same sequence number. The default value for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. Section 6.5 - OC-Sequence-Number As resolution to issue 82, change the following: From the functionality point of view, the OC-Sequence-Number AVP MUST be used as a non-volatile increasing counter between two DOIC nodes. To: From the functionality point of view, the OC-Sequence-Number AVP MUST be used as a non-volatile increasing counter for a sequence of overload reports between two DOIC nodes for the same overload occurrence. Moved the following to section 4.2.3 Reporting Node Behavior (for overload report handling) When generating sequence numbers, the new sequence number MUST be greater than any sequence number in an active overload report previously sent by the reporting node. This property MUST hold over a reboot of the reporting node. Added the following to section 4.2.3: If OLR is for a new overload condition and there is no unexpired overload report for previous overload conditions at any reacting node then the reporting node MAY set the sequence number to any value. The reacting node MAY update the overload report with new reduction percentages. When doing so, the reacting node MUST increase the sequence number in the new OLR sent. When generating sequence numbers for , the new sequence number MUST be greater than any sequence number in an active (unexpired) overload report previously sent by the reporting node. This property MUST hold over a reboot of the reporting node. Section 6.5 OC-Validity-Duration AVP: Removed the following: When a reporting node has recovered from overload, it SHOULD invalidate any existing overload reports in a timely matter. This can be achieved by sending an updated overload report (meaning the OLR contains a new sequence number) with the OC-Validity-Duration AVP value set to zero ("0"). If the overload report is about to expire naturally, the reporting node MAY choose to simply let it do so. A reacting node MUST invalidate and remove an overload report that expires without an explicit overload report containing an OC- Validity-Duration value set to zero ("0"). Section 6.6 OC-Report-Type Removed the following editor's note: Editor's note: There is still an open issue on the definition of Realm reports and whether what report types should be supported. There is consensus that host reports should be supported. There is discussion on Realm reports and Realm-Routed-Request reports. The above definition applies to Realm-Routed-Request reports where Realm reports are defined to apply to all requests that match the realm, independent of the presence, absence or value of the Destination-Host AVP. --------------020405030206080004040302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit With this update I did a scrub of avp description, removing behavior definitions that are already in other sections.  There were also a few editorial changes mixed in.

I've attached the diff file and a summary of the changes follows.

Regards,

Steve

-----

Section 6.1 OC-Supported-Features

Removed the following which is covered in the section on Capability Announcement:
   A reacting node includes this AVP to indicate its capabilities to a
   reporting node.  For example, the reacting node may indicate which
   (future defined) traffic abatement algorithms it supports in addition
   to the default.

   During the message exchange the DOIC nodes express their common set
   of supported capabilities.  The reacting node includes the OC-
   Supported-Features AVP that announces what it supports.  The
   reporting node that sends the answer also includes the OC-Supported-
   Features AVP that describes the capabilities it supports.  The set of
   capabilities advertised by the reporting node depends on local
   policies.  Since the loss abatement algorithm Section 5 is mandatory
   to implement DOIC can always be enabled between these DOIC nodes.
Also changed the following in section 4.1.1, as the OC-Feature-Vector is an optional parameter:

Old text:
   A reacting node MUST include the OC-Feature-Vector AVP with an
   indication of the loss algorithm.
New text

A reacting node MAY include the OC-Feature-Vector AVP with an indication of the loss algorithm.  A reacting node MUST include the OC-Feature-Vector AVP to indicate support for abatement algorithms in addition to the loss algorithm.

6.3 OC-OLR

Removed the following, it belongs in the OC-Validity-Duration AVP section:

   The OC-Validity-Duration AVP indicates the validity time of the
   overload report associated with a specific sequence number, measured
   after reception of the OC-OLR AVP.  The validity time MUST NOT be
   updated after reception of subsequent OC-OLR AVPs with the same
   sequence number.  The default value for the OC-Validity-Duration AVP
   value is 5 (i.e., 5 seconds).  When the OC-Validity-Duration AVP is
   not present in the OC-OLR AVP, the default value applies.
Section 6.5 - OC-Sequence-Number

As resolution to issue 82, change the following:
   From the functionality point of view, the OC-Sequence-Number AVP MUST
   be used as a non-volatile increasing counter between two DOIC nodes.
To:

         From the functionality point of view, the OC-Sequence-Number AVP MUST
         be used as a non-volatile increasing counter for a sequence of overload reports
         between two DOIC nodes for the same overload occurrence.

Moved the following to section 4.2.3 Reporting Node Behavior (for overload report handling)

   When generating sequence numbers, the new sequence number MUST be
   greater than any sequence number in an active overload report
   previously sent by the reporting node.  This property MUST hold over
   a reboot of the reporting node.
Added the following to section 4.2.3:

          If OLR is for a new overload condition and there is no unexpired 
          overload report for previous overload conditions
          at any reacting node then the reporting node MAY
          set the sequence number to any value.

          The reacting node MAY update the overload report with new reduction
          percentages.  When doing so, the reacting node MUST increase the
          sequence number in the new OLR sent.

          When generating sequence numbers for , the new sequence number MUST be
          greater than any sequence number in an active (unexpired) overload report
          previously sent by the reporting node.  This property MUST hold over
          a reboot of the reporting node.

Section 6.5 OC-Validity-Duration AVP:

Removed the following:

   When a reporting node has recovered from overload, it SHOULD
   invalidate any existing overload reports in a timely matter.  This
   can be achieved by sending an updated overload report (meaning the
   OLR contains a new sequence number) with the OC-Validity-Duration AVP
   value set to zero ("0").  If the overload report is about to expire
   naturally, the reporting node MAY choose to simply let it do so.

   A reacting node MUST invalidate and remove an overload report that
   expires without an explicit overload report containing an OC-
   Validity-Duration value set to zero ("0").
Section 6.6 OC-Report-Type

Removed the following editor's note:

      Editor's note: There is still an open issue on the definition of
      Realm reports and whether what report types should be supported.
      There is consensus that host reports should be supported.  There
      is discussion on Realm reports and Realm-Routed-Request reports.
      The above definition applies to Realm-Routed-Request reports where
      Realm reports are defined to apply to all requests that match the
      realm, independent of the presence, absence or value of the
      Destination-Host AVP.









--------------020405030206080004040302-- --------------020200010607080807080507 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 2, line 28 skipping to change at page 2, line 28
3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7
3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 8 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 8
3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10
3.5. Simplified Example Architecture . . . . . . . . . . . . . 10 3.5. Simplified Example Architecture . . . . . . . . . . . . . 10
4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11
4.1. Capability Announcement . . . . . . . . . . . . . . . . . 11 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 11
4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12
4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12
4.2. Overload Report Processing . . . . . . . . . . . . . . . 13 4.2. Overload Report Processing . . . . . . . . . . . . . . . 13
4.2.1. Overload Control State . . . . . . . . . . . . . . . 13 4.2.1. Overload Control State . . . . . . . . . . . . . . . 13
4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 15 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16
4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17
4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 18 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 19
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 19 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 20 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 21
5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 22 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 22
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 24 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 24
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 26 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 26
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 29 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 29
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 29
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 30 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 29
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Issues left for future specifications . . . . . . . 32 Appendix A. Issues left for future specifications . . . . . . . 32
A.1. Additional traffic abatement algorithms . . . . . . . . . 32 A.1. Additional traffic abatement algorithms . . . . . . . . . 32
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 32 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 32
A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 33 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 32
Appendix B. Deployment Considerations . . . . . . . . . . . . . 33 Appendix B. Deployment Considerations . . . . . . . . . . . . . 32
Appendix C. Considerations for Applications Integrating the DOIC Appendix C. Considerations for Applications Integrating the DOIC
Solution . . . . . . . . . . . . . . . . . . . . . . 33 Solution . . . . . . . . . . . . . . . . . . . . . . 33
C.1. Application Classification . . . . . . . . . . . . . . . 33 C.1. Application Classification . . . . . . . . . . . . . . . 33
C.2. Application Type Overload Implications . . . . . . . . . 34 C.2. Application Type Overload Implications . . . . . . . . . 34
C.3. Request Transaction Classification . . . . . . . . . . . 36 C.3. Request Transaction Classification . . . . . . . . . . . 35
C.4. Request Type Overload Implications . . . . . . . . . . . 36 C.4. Request Type Overload Implications . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
This specification defines a base solution for Diameter Overload This specification defines a base solution for Diameter Overload
Control (DOC), refered to as Diameter Overload Indication Conveyance Control (DOC), refered to as Diameter Overload Indication Conveyance
(DOIC). The requirements for the solution are described and (DOIC). The requirements for the solution are described and
discussed in the corresponding design requirements document discussed in the corresponding design requirements document
[RFC7068]. Note that the overload control solution defined in this [RFC7068]. Note that the overload control solution defined in this
specification does not address all the requirements listed in specification does not address all the requirements listed in
[RFC7068]. A number of overload control related features are left [RFC7068]. A number of overload control related features are left
skipping to change at page 12, line 20 skipping to change at page 12, line 20
agent does not include the OC-Supported-Features AVP then the DOIC agent does not include the OC-Supported-Features AVP then the DOIC
agent inserts the AVP. If the message already has the AVP then the agent inserts the AVP. If the message already has the AVP then the
agent either leaves it unchanged in the relayed message or modifies agent either leaves it unchanged in the relayed message or modifies
it to reflect a mixed set of DOIC features. it to reflect a mixed set of DOIC features.
4.1.1. Reacting Node Behavior 4.1.1. Reacting Node Behavior
A reacting node MUST include the OC-Supported-Features AVP in all A reacting node MUST include the OC-Supported-Features AVP in all
request messages. request messages.
A reacting node MUST include the OC-Feature-Vector AVP with an A reacting node MAY include the OC-Feature-Vector AVP with an
indication of the loss algorithm. indication of the loss algorithm. A reacting node MUST include the
OC-Feature-Vector AVP to indicate support for abatement algorithms in
addition to the loss algorithm.
A reacting node SHOULD indicate support for all other DOIC features A reacting node SHOULD indicate support for all other DOIC features
it supports. it supports.
An OC-Supported-Features AVP in answer messages indicates there is a An OC-Supported-Features AVP in answer messages indicates there is a
reporting node for the transaction. The reacting node MAY take reporting node for the transaction. The reacting node MAY take
action based on the features indicated in the OC-Feature-Vector AVP. action based on the features indicated in the OC-Feature-Vector AVP.
Note that the loss abatement algorithm is the only feature Note that the loss abatement algorithm is the only feature
described in this document and it does not require action to be described in this document and it does not require action to be
skipping to change at page 17, line 14 skipping to change at page 17, line 23
sequence number, the reacting node MUST update the overload control sequence number, the reacting node MUST update the overload control
state associated with the realm or the specific node in the realm. state associated with the realm or the specific node in the realm.
When an overload control state is created or updated, the reacting When an overload control state is created or updated, the reacting
node MUST apply the traffic abatement requested in the OC-OLR AVP node MUST apply the traffic abatement requested in the OC-OLR AVP
using the algorithm announced in the OC-Supported-Features AVP using the algorithm announced in the OC-Supported-Features AVP
contained in the received answer message along with the OC-OLR AVP. contained in the received answer message along with the OC-OLR AVP.
The validity duration of the overload information contained in the The validity duration of the overload information contained in the
OC-OLR AVP is either explicitly indicated in the OC-Validity-Duration OC-OLR AVP is either explicitly indicated in the OC-Validity-Duration
AVP or is implicitly equals to the default value (5 seconds) if the AVP or is implicitly equals to the default value if the OC-Validity-
OC-Validity-Duration AVP is absent. The reacting node MUST maintain Duration AVP is absent. The reacting node MUST maintain the validity
the validity duration in the overload control state. Once the duration in the overload control state. Once the validity duration
validity duration times out, the reacting node MUST assume the times out, the reacting node MUST assume the overload condition
overload condition reported in a previous OC-OLR AVP has ended. reported in a previous OC-OLR AVP has ended.
A value of zero ("0") received in the OC-Validity-Duration in an A value of zero ("0") received in the OC-Validity-Duration in an
updated overload report indicates that the overload condition has updated overload report indicates that the overload condition has
ended and that the overload state is no longer valid. ended and that the overload state is no longer valid.
In the case that the validity duration expires or is explicitly In the case that the validity duration expires or is explicitly
signaled as being no longer valid the state associated with the signaled as being no longer valid the state associated with the
overload report MUST be removed and any abatement associated with the overload report MUST be removed and any abatement associated with the
overload report MUST be ended in a controlled fashion. After overload report MUST be ended in a controlled fashion. After
removing the overload state the sequence number MUST NOT be used for removing the overload state the sequence number MUST NOT be used for
skipping to change at page 18, line 5 skipping to change at page 18, line 12
request message. Since the loss abatement algorithm Section 5 is request message. Since the loss abatement algorithm Section 5 is
mandatory to implement DOIC can always be enabled between these DOIC mandatory to implement DOIC can always be enabled between these DOIC
nodes See Section 4.1 for further discussion on the capability and nodes See Section 4.1 for further discussion on the capability and
feature announcement. feature announcement.
When a traffic reduction is required due to an overload condition and When a traffic reduction is required due to an overload condition and
the overload control solution is supported by the sender of the the overload control solution is supported by the sender of the
Diameter request, the reporting node SHOULD include an OC-Supported- Diameter request, the reporting node SHOULD include an OC-Supported-
Features AVP and an OC-OLR AVP in the corresponding Diameter answer. Features AVP and an OC-OLR AVP in the corresponding Diameter answer.
A reporting node MAY choose to not send an overload report to a A reporting node MAY choose to not resend an overload report to a
reacting node if it can guarantee that this overload report is reacting node if it can guarantee that this overload report is
already active in the reacting node. already active in the reacting node.
Note - In some cases (e.g. when there are one or multiple agents Note - In some cases (e.g. when there are one or multiple agents
in the path between reporting and reacting nodes, or when overload in the path between reporting and reacting nodes, or when overload
reports are discarded by reacting nodes) the reporting node may reports are discarded by reacting nodes) the reporting node may
not be able to guarantee that the reacting node has received the not be able to guarantee that the reacting node has received the
report. report.
The OC-OLR AVP contains the required traffic reduction and the OC- The OC-OLR AVP contains the required traffic reduction and the OC-
skipping to change at page 18, line 28 skipping to change at page 18, line 35
the request sender. the request sender.
A reporting node MUST only send overload reports of a type advertised A reporting node MUST only send overload reports of a type advertised
as supported by the reacting node. as supported by the reacting node.
Note that a reacting node advertises support for the host and Note that a reacting node advertises support for the host and
realm report types by including the OC-Supported-Features AVP in realm report types by including the OC-Supported-Features AVP in
the request. Support for other report types must be explicitly the request. Support for other report types must be explicitly
indicated by a new feature bit in the OC-Feature-Vector AVP. indicated by a new feature bit in the OC-Feature-Vector AVP.
If OLR is for a new overload condition and there is no unexpired
overload report for previous overload conditions at any reacting node
then the reporting node MAY set the sequence number to any value.
The reacting node MAY update the overload report with new reduction
percentages. When doing so, the reacting node MUST increase the
sequence number in the new OLR sent.
When generating sequence numbers for , the new sequence number MUST
be greater than any sequence number in an active (unexpired) overload
report previously sent by the reporting node. This property MUST
hold over a reboot of the reporting node.
A reporting node MAY rely on the OC-Validity-Duration AVP values for A reporting node MAY rely on the OC-Validity-Duration AVP values for
the implicit overload control state cleanup on the reacting node. the implicit overload control state cleanup on the reacting node.
However, it is RECOMMENDED that the reporting node always explicitly However, it is RECOMMENDED that the reporting node always explicitly
indicates the end of a overload condition. indicates the end of a overload condition.
The reporting node SHOULD indicate the end of an overload occurrence The reporting node SHOULD indicate the end of an overload occurrence
by sending a new OLR with OC-Validity-Duration set to a value of zero by sending a new OLR with OC-Validity-Duration set to a value of zero
("0"). The reporting node SHOULD insure that all reacting nodes ("0"). The reporting node SHOULD insure that all reacting nodes
receive the updated overload report. receive the updated overload report.
skipping to change at page 22, line 26 skipping to change at page 22, line 41
mechanism specified in this document by making it mandatory to mechanism specified in this document by making it mandatory to
implement for the application and referencing this specification implement for the application and referencing this specification
normatively. In such a case, the rules for handling of the M-bit normatively. In such a case, the rules for handling of the M-bit
must follow the guidance in [RFC6733]. It is the responsibility of must follow the guidance in [RFC6733]. It is the responsibility of
the Diameter application designers to define how overload control the Diameter application designers to define how overload control
mechanisms works on that application. mechanisms works on that application.
6.1. OC-Supported-Features AVP 6.1. OC-Supported-Features AVP
The OC-Supported-Features AVP (AVP code TBD1) is type of Grouped and The OC-Supported-Features AVP (AVP code TBD1) is type of Grouped and
serves for two purposes. First, it announces a node's support for serves two purposes. First, it announces a node's support for the
the DOIC in general. Second, it contains the description of the DOIC solution in general. Second, it contains the description of the
supported DOIC features of the sending node. The OC-Supported- supported DOIC features of the sending node. The OC-Supported-
Features AVP MUST be included in every Diameter message a DOIC Features AVP MUST be included in every Diameter message a DOIC
supporting node sends. supporting node sends.
OC-Supported-Features ::= < AVP Header: TBD1 > OC-Supported-Features ::= < AVP Header: TBD1 >
[ OC-Feature-Vector ] [ OC-Feature-Vector ]
* [ AVP ] * [ AVP ]
The OC-Feature-Vector sub-AVP is used to announce the DOIC features The OC-Feature-Vector sub-AVP is used to announce the DOIC features
supported by the DOIC node, in the form of a flag bits field in which supported by the DOIC node, in the form of a flag bits field in which
each bit announces one feature or capability supported by the node each bit announces one feature or capability supported by the node
(see Section 6.2). The absence of the OC-Feature-Vector AVP (see Section 6.2). The absence of the OC-Feature-Vector AVP
indicates that only the default traffic abatement algorithm described indicates that only the default traffic abatement algorithm described
in this specification is supported. in this specification is supported.
A reacting node includes this AVP to indicate its capabilities to a
reporting node. For example, the reacting node may indicate which
(future defined) traffic abatement algorithms it supports in addition
to the default.
During the message exchange the DOIC nodes express their common set
of supported capabilities. The reacting node includes the OC-
Supported-Features AVP that announces what it supports. The
reporting node that sends the answer also includes the OC-Supported-
Features AVP that describes the capabilities it supports. The set of
capabilities advertised by the reporting node depends on local
policies. Since the loss abatement algorithm Section 5 is mandatory
to implement DOIC can always be enabled between these DOIC nodes.
6.2. OC-Feature-Vector AVP 6.2. OC-Feature-Vector AVP
The OC-Feature-Vector AVP (AVP code TBD6) is type of Unsigned64 and The OC-Feature-Vector AVP (AVP code TBD6) is type of Unsigned64 and
contains a 64 bit flags field of announced capabilities of a DOIC contains a 64 bit flags field of announced capabilities of a DOIC
node. The value of zero (0) is reserved. node. The value of zero (0) is reserved.
The following capabilities are defined in this document: The following capabilities are defined in this document:
OLR_DEFAULT_ALGO (0x0000000000000001) OLR_DEFAULT_ALGO (0x0000000000000001)
When this flag is set by the DOIC node it means that the default When this flag is set by the DOIC node it means that the default
traffic abatement (loss) algorithm is supported. traffic abatement (loss) algorithm is supported.
6.3. OC-OLR AVP 6.3. OC-OLR AVP
The OC-OLR AVP (AVP code TBD2) is type of Grouped and contains the The OC-OLR AVP (AVP code TBD2) is type of Grouped and contains the
necessary information to convey an overload report. The OC-OLR AVP information necessary to convey an overload report. The OC-OLR AVP
does not explicitly contain all information needed by the reacting does not explicitly contain all information needed by the reacting
node to decide whether a subsequent request must undergo a throttling node to decide whether a subsequent request must undergo a throttling
process with the received reduction percentage. The value of the OC- process with the received reduction percentage. The value of the OC-
Report-Type AVP within the OC-OLR AVP indicates which implicit Report-Type AVP within the OC-OLR AVP indicates which implicit
information is relevant for this decision (see Section 6.6). The information is relevant for this decision (see Section 6.6). The
application the OC-OLR AVP applies to is the same as the Application- application the OC-OLR AVP applies to is the same as the Application-
Id found in the Diameter message header. The identity the OC-OLR AVP Id found in the Diameter message header. The host or realm the OC-
concerns is determined from the Origin-Host AVP (and Origin-Realm AVP OLR AVP concerns is determined from the Origin-Host AVP and/or
as well) found from the encapsulating Diameter command. The OC-OLR Origin-Realm AVP found in the encapsulating Diameter command. The
AVP is intended to be sent only by a reporting node. OC-OLR AVP is intended to be sent only by a reporting node.
OC-OLR ::= < AVP Header: TBD2 > OC-OLR ::= < AVP Header: TBD2 >
< OC-Sequence-Number > < OC-Sequence-Number >
< OC-Report-Type > < OC-Report-Type >
[ OC-Reduction-Percentage ] [ OC-Reduction-Percentage ]
[ OC-Validity-Duration ] [ OC-Validity-Duration ]
* [ AVP ] * [ AVP ]
The OC-Validity-Duration AVP indicates the validity time of the
overload report associated with a specific sequence number, measured
after reception of the OC-OLR AVP. The validity time MUST NOT be
updated after reception of subsequent OC-OLR AVPs with the same
sequence number. The default value for the OC-Validity-Duration AVP
value is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is
not present in the OC-OLR AVP, the default value applies.
Note that if a Diameter command were to contain multiple OC-OLR AVPs Note that if a Diameter command were to contain multiple OC-OLR AVPs
they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs
with unknown values SHOULD be silently discarded and the event SHOULD with unknown values SHOULD be silently discarded and the event SHOULD
be logged. be logged.
6.4. OC-Sequence-Number AVP 6.4. OC-Sequence-Number AVP
The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64. The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
Its usage in the context of overload control is described in Its usage in the context of overload control is described in
Section 4.2. Section 4.2.
From the functionality point of view, the OC-Sequence-Number AVP MUST From the functionality point of view, the OC-Sequence-Number AVP MUST
be used as a non-volatile increasing counter between two DOIC nodes. be used as a non-volatile increasing counter for a sequence of
The sequence number is only required to be unique between two DOIC overload reports between two DOIC nodes for the same overload
nodes. Sequence numbers are treated in a uni-directional manner, occurrence. The sequence number is only required to be unique
i.e. two sequence numbers on each direction between two DOIC nodes between two DOIC nodes. Sequence numbers are treated in a uni-
are not related or correlated. directional manner, i.e. two sequence numbers on each direction
between two DOIC nodes are not related or correlated.
When generating sequence numbers, the new sequence number MUST be When generating sequence numbers, the new sequence number MUST be
greater than any sequence number in an active overload report greater than any sequence number in an active, unexpired, overload
previously sent by the reporting node. This property MUST hold over report previously sent by the reporting node. This property MUST
a reboot of the reporting node. hold over a reboot of the reporting node.
6.5. OC-Validity-Duration AVP 6.5. OC-Validity-Duration AVP
The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
and indicates in seconds the validity time of the overload report. and indicates in seconds the validity time of the overload report.
The number of seconds is measured after reception of the first OC-OLR The number of seconds is measured after reception of the first OC-OLR
AVP with a given value of OC-Sequence-Number AVP. The default value AVP with a given value of OC-Sequence-Number AVP. The default value
for the OC-Validity-Duration AVP is 5 (i.e., 5 seconds). When the for the OC-Validity-Duration AVP is 5 (i.e., 5 seconds). When the
OC-Validity-Duration AVP is not present in the OC-OLR AVP, the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the
default value applies. Validity duration with values above 86400 default value applies. Validity duration with values above 86400
skipping to change at page 25, line 47 skipping to change at page 25, line 43
The Destination-Host AVP is absent in the request. The Destination-Host AVP is absent in the request.
The value of the Destination-Realm AVP in the request matches the The value of the Destination-Realm AVP in the request matches the
value of the Origin-Realm AVP of the received message that value of the Origin-Realm AVP of the received message that
contained the OC-OLR AVP. contained the OC-OLR AVP.
The value of the Application-ID in the Diameter Header of the The value of the Application-ID in the Diameter Header of the
request matches the value of the Application-ID of the Diameter request matches the value of the Application-ID of the Diameter
Header of the received message that contained the OC-OLR AVP. Header of the received message that contained the OC-OLR AVP.
Editor's note: There is still an open issue on the definition of
Realm reports and whether what report types should be supported.
There is consensus that host reports should be supported. There
is discussion on Realm reports and Realm-Routed-Request reports.
The above definition applies to Realm-Routed-Request reports where
Realm reports are defined to apply to all requests that match the
realm, independent of the presence, absence or value of the
Destination-Host AVP.
The OC-Report-Type AVP is envisioned to be useful for situations The OC-Report-Type AVP is envisioned to be useful for situations
where a reacting node needs to apply different overload treatments where a reacting node needs to apply different overload treatments
for different "types" of overload. For example, the reacting node(s) for different "types" of overload. For example, the reacting node(s)
might need to throttle differently requests sent to a specific server might need to throttle differently requests sent to a specific server
(identified by the Destination-Host AVP in the request) and requests (identified by the Destination-Host AVP in the request) and requests
that can be handled by any server in a realm. that can be handled by any server in a realm.
6.7. OC-Reduction-Percentage AVP 6.7. OC-Reduction-Percentage AVP
The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32 The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
 End of changes. 20 change blocks. 
69 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------020200010607080807080507-- From nobody Tue Oct 21 00:06:57 2014 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 0B5531A6EE4 for ; Mon, 20 Oct 2014 10:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 RxWLKut5ufio for ; Mon, 20 Oct 2014 10:03:15 -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 C603C1A8A0F for ; Mon, 20 Oct 2014 09:50:47 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:53107 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgGAP-0000vs-23 for dime@ietf.org; Mon, 20 Oct 2014 09:50:46 -0700 Message-ID: <54453D64.8030001@usdonovans.com> Date: Mon, 20 Oct 2014 18:50:44 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------090806050006080704070208" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/LDVZen989yM5QeOsNccBPNoy3Xo X-Mailman-Approved-At: Tue, 21 Oct 2014 00:06:24 -0700 Subject: [Dime] Resolution of Editor's Notes 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, 20 Oct 2014 17:03:19 -0000 This is a multi-part message in MIME format. --------------090806050006080704070208 Content-Type: multipart/alternative; boundary="------------020605000706040506050305" --------------020605000706040506050305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit With this pass I attempted to resolve all Editor's Notes, as outlined below. I've attached the diff file. Regards, Steve --- Section 2 - This editor's note will be resolved when the issue on defining new terms is resolved. As such, it is still in the document. Section 4.2.1.2. Removed the following paragraph plus the Editor's Note below it: Overload Control States for reporting nodes containing a validity duration of 0 sec. should not expire before any previously sent (stale) OLR has timed out at any reacting node. Editor's note: This statement is unclear and contradictory with other statements. A validity timer of zero seconds indicates that the overload condition has ended and abatement is no longer requested. Section 4.2.2 Removed the following Editor's note as this issue has been resolved: Editor's note: The above behavior for Realm reports is inconsistent with the definition of realm reports in section Section 6.6. Section 7 - This editor's note deals with the response code issue resolution and will be removed when that issue is resolved. In summary, two Editor's Notes remain and they are tied to currently open issues. --------------020605000706040506050305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit With this pass I attempted to resolve all Editor's Notes, as outlined below.

I've attached the diff file.

Regards,

Steve
---

Section 2 - This editor's note will be resolved when the issue on defining new terms is resolved.  As such, it is still in the document.

Section 4.2.1.2.

Removed the following paragraph plus the Editor's Note below it:
   Overload Control States for reporting nodes containing a validity
   duration of 0 sec. should not expire before any previously sent
   (stale) OLR has timed out at any reacting node.

   Editor's note: This statement is unclear and contradictory with other
   statements.  A validity timer of zero seconds indicates that the
   overload condition has ended and abatement is no longer requested.
Section 4.2.2

Removed the following Editor's note as this issue has been resolved:

      Editor's note: The above behavior for Realm reports is
      inconsistent with the definition of realm reports in section
      Section 6.6.
Section 7 - This editor's note deals with the response code issue resolution and will be removed when that issue is resolved.

In summary, two Editor's Notes remain and they are tied to currently open issues.
--------------020605000706040506050305-- --------------090806050006080704070208 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 2, line 28 skipping to change at page 2, line 28
3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7
3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 8 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 8
3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10
3.5. Simplified Example Architecture . . . . . . . . . . . . . 10 3.5. Simplified Example Architecture . . . . . . . . . . . . . 10
4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11
4.1. Capability Announcement . . . . . . . . . . . . . . . . . 11 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 11
4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12
4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12
4.2. Overload Report Processing . . . . . . . . . . . . . . . 13 4.2. Overload Report Processing . . . . . . . . . . . . . . . 13
4.2.1. Overload Control State . . . . . . . . . . . . . . . 13 4.2.1. Overload Control State . . . . . . . . . . . . . . . 13
4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 15
4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17
4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 19 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 19
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 21 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 20
5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 22 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 22
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 24 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 23
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 24
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 25
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 26 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 26
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 27 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 29 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 29
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 29 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 29
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 29 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 29
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Issues left for future specifications . . . . . . . 32 Appendix A. Issues left for future specifications . . . . . . . 31
A.1. Additional traffic abatement algorithms . . . . . . . . . 32 A.1. Additional traffic abatement algorithms . . . . . . . . . 32
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 32 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 32
A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 32 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 32
Appendix B. Deployment Considerations . . . . . . . . . . . . . 32 Appendix B. Deployment Considerations . . . . . . . . . . . . . 32
Appendix C. Considerations for Applications Integrating the DOIC Appendix C. Considerations for Applications Integrating the DOIC
Solution . . . . . . . . . . . . . . . . . . . . . . 33 Solution . . . . . . . . . . . . . . . . . . . . . . 33
C.1. Application Classification . . . . . . . . . . . . . . . 33 C.1. Application Classification . . . . . . . . . . . . . . . 33
C.2. Application Type Overload Implications . . . . . . . . . 34 C.2. Application Type Overload Implications . . . . . . . . . 34
C.3. Request Transaction Classification . . . . . . . . . . . 35 C.3. Request Transaction Classification . . . . . . . . . . . 35
C.4. Request Type Overload Implications . . . . . . . . . . . 36 C.4. Request Type Overload Implications . . . . . . . . . . . 36
skipping to change at page 14, line 44 skipping to change at page 14, line 44
o Report type o Report type
o Sequence number o Sequence number
o Validity Duration and Expiry Time o Validity Duration and Expiry Time
o Algorithm specific input data (e.g. Reduction Percentage for o Algorithm specific input data (e.g. Reduction Percentage for
Loss) Loss)
Overload Control States for reporting nodes containing a validity
duration of 0 sec. should not expire before any previously sent
(stale) OLR has timed out at any reacting node.
Editor's note: This statement is unclear and contradictory with other
statements. A validity timer of zero seconds indicates that the
overload condition has ended and abatement is no longer requested.
4.2.1.3. Maintaining Overload Control State 4.2.1.3. Maintaining Overload Control State
Reacting nodes create a host-type OCS identified by OCS-Id = (app- Reacting nodes create a host-type OCS identified by OCS-Id = (app-
id,host-id) when receiving an answer message of application app-id id,host-id) when receiving an answer message of application app-id
containing an Orig-Host of host-id and a host-type OC-OLR AVP unless containing an Orig-Host of host-id and a host-type OC-OLR AVP unless
such host-type OCS already exists. such host-type OCS already exists.
Reacting nodes create a realm-type OCS identified by OCS-Id = (app- Reacting nodes create a realm-type OCS identified by OCS-Id = (app-
id,realm-id) when receiving an answer message of application app-id id,realm-id) when receiving an answer message of application app-id
containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP
skipping to change at page 16, line 46 skipping to change at page 16, line 32
idea is that the reacting node applies different handling of the idea is that the reacting node applies different handling of the
traffic abatement, whether sent request messages are targeted to a traffic abatement, whether sent request messages are targeted to a
specific host (identified by the Diameter-Host AVP in the request) or specific host (identified by the Diameter-Host AVP in the request) or
to any host in a realm (when only the Destination-Realm AVP is to any host in a realm (when only the Destination-Realm AVP is
present in the request). Note that future specifications MAY define present in the request). Note that future specifications MAY define
new OC-Report-Type AVP values that imply different handling of the new OC-Report-Type AVP values that imply different handling of the
OC-OLR AVP. For example, in a form of new additional AVPs inside the OC-OLR AVP. For example, in a form of new additional AVPs inside the
Grouped OC-OLR AVP that would define report target in a finer Grouped OC-OLR AVP that would define report target in a finer
granularity than just a host. granularity than just a host.
Editor's note: The above behavior for Realm reports is
inconsistent with the definition of realm reports in section
Section 6.6.
If the OC-OLR AVP is received for the first time, the reacting node If the OC-OLR AVP is received for the first time, the reacting node
MUST create overload control state associated with the related realm MUST create overload control state associated with the related realm
or a specific host in the realm identified in the message carrying or a specific host in the realm identified in the message carrying
the OC-OLR AVP, as described in Section 4.2.1. the OC-OLR AVP, as described in Section 4.2.1.
If the value of the OC-Sequence-Number AVP contained in the received If the value of the OC-Sequence-Number AVP contained in the received
OC-OLR AVP is equal to or less than the value stored in an existing OC-OLR AVP is equal to or less than the value stored in an existing
overload control state, the received OC-OLR AVP SHOULD be silently overload control state, the received OC-OLR AVP SHOULD be silently
discarded. If the value of the OC-Sequence-Number AVP contained in discarded. If the value of the OC-Sequence-Number AVP contained in
the received OC-OLR AVP is greater than the value stored in an the received OC-OLR AVP is greater than the value stored in an
 End of changes. 8 change blocks. 
19 lines changed or deleted 7 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------090806050006080704070208-- From nobody Tue Oct 21 00:14:41 2014 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 DD07E1AD069 for ; Tue, 21 Oct 2014 00:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.179 X-Spam-Level: ** X-Spam-Status: No, score=2.179 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_24=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 pJhpuZwvEP-Q for ; Tue, 21 Oct 2014 00:14:28 -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 082C31AD068 for ; Tue, 21 Oct 2014 00:14:28 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:54853 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgTe4-000AGL-FA for dime@ietf.org; Tue, 21 Oct 2014 00:14:27 -0700 Message-ID: <544607C7.9070201@usdonovans.com> Date: Tue, 21 Oct 2014 09:14:15 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------040602090603050609000905" 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Oh5crbr7xMArpUhF67EzPcGWfVk Subject: [Dime] Snapshot of -04 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, 21 Oct 2014 07:14:39 -0000 This is a multi-part message in MIME format. --------------040602090603050609000905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've attached the latest snapshot of the -04 draft resulting from yesterday's changes. I would expect fewer changes today. Steve --------------040602090603050609000905 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-dime-ovli-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-dime-ovli-04.txt" Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed. Internet-Draft Broadcom Intended status: Standards Track S. Donovan, Ed. Expires: April 23, 2015 B. Campbell Oracle L. Morand Orange Labs October 20, 2014 Diameter Overload Indication Conveyance draft-ietf-dime-ovli-04.txt Abstract This specification documents a Diameter Overload Control (DOC) base solution and the dissemination of the overload report information. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 23, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Korhonen, et al. Expires April 23, 2015 [Page 1] Internet-Draft DOIC October 2014 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 6 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 8 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10 3.5. Simplified Example Architecture . . . . . . . . . . . . . 10 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 11 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 4.2. Overload Report Processing . . . . . . . . . . . . . . . 13 4.2.1. Overload Control State . . . . . . . . . . . . . . . 13 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 15 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 19 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 19 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 20 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 22 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 23 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 24 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 25 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 26 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 27 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 29 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 29 Korhonen, et al. Expires April 23, 2015 [Page 2] Internet-Draft DOIC October 2014 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 29 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . 31 Appendix A. Issues left for future specifications . . . . . . . 31 A.1. Additional traffic abatement algorithms . . . . . . . . . 32 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 32 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 32 Appendix B. Deployment Considerations . . . . . . . . . . . . . 32 Appendix C. Considerations for Applications Integrating the DOIC Solution . . . . . . . . . . . . . . . . . . . . . . 33 C.1. Application Classification . . . . . . . . . . . . . . . 33 C.2. Application Type Overload Implications . . . . . . . . . 34 C.3. Request Transaction Classification . . . . . . . . . . . 35 C.4. Request Type Overload Implications . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction This specification defines a base solution for Diameter Overload Control (DOC), refered to as Diameter Overload Indication Conveyance (DOIC). The requirements for the solution are described and discussed in the corresponding design requirements document [RFC7068]. Note that the overload control solution defined in this specification does not address all the requirements listed in [RFC7068]. A number of overload control related features are left for the future specifications. The solution defined in this specification addresses Diameter overload control between Diameter nodes that support the DOIC solution. Furthermore, the solution is designed to apply to existing and future Diameter applications, requires no changes to the Diameter base protocol [RFC6733] and is deployable in environments where some Diameter nodes do not implement the Diameter overload control solution defined in this specification. 2. Terminology and Abbreviations Abatement Algorithm An algorithm requested by reporting nodes and used by reacting nodes to reduce the amount of traffic sent during an occurrence of overload control. Throttling Korhonen, et al. Expires April 23, 2015 [Page 3] Internet-Draft DOIC October 2014 Throttling is the reduction of the number of requests sent to an entity. Throttling can include a client dropping requests, or an agent rejecting requests with appropriate error responses. Clients and agents can also choose to redirect throttled requests to some other entity or entities capable of handling them. Editor's note: Propose to add a definition of Abatement to include both throttling and diversion (redirecting of messages) actions. Then to modify this definition to include just the rejecting of requests and adding a definition of diversion. Reporting Node A Diameter node that generates an overload report. (This may or may not be the overloaded node.) Reacting Node A Diameter node that consumes and acts upon a report. Note that "act upon" does not necessarily mean the reacting node applies an abatement algorithm; it might decide to delegate that downstream, in which case it also becomes a "reporting node". Overload Control State (OCS) State describing an occurrence of overload control maintained by reporting and reacting nodes. Overload Report (OLR) A set of AVPs sent by a reporting node indicating the start or continuation of an occurrence of overload control. 3. Solution Overview The Diameter Overload Information Conveyance (DOIC) mechanism allows Diameter nodes to request other nodes to perform overload abatement actions, that is, actions to reduce the load offered to the overloaded node or realm. A Diameter node that supports DOIC is known as a "DOIC node". Any Diameter node can act as a DOIC node, including clients, servers, and agents. DOIC nodes are further divided into "Reporting Nodes" and "Reacting Nodes." A reporting node requests overload abatement by sending an Overload Report (OLR) to one or more reacting nodes. A reacting node consumes OLRs, and performs whatever actions are needed to fulfill the abatement requests included in the OLRs. A Korhonen, et al. Expires April 23, 2015 [Page 4] Internet-Draft DOIC October 2014 Reporting node may report overload on its own behalf, or on behalf of other (typically upstream) nodes. Likewise, a reacting node may perform overload abatement on its own behalf, or on behalf of other (typically downstream) nodes. A node's role as a DOIC node is independent of its Diameter role. For example, Diameter relay and proxy agents may act as DOIC nodes, even though they are not endpoints in the Diameter sense. Since Diameter enables bi-directional applications, where Diameter servers can send requests towards Diameter clients, a given Diameter node can simultaneously act as a reporting node and a reacting node. Likewise, a relay or proxy agent may act as a reacting node from the perspective of upstream nodes, and a reporting node from the perspective of downstream nodes. DOIC nodes do not generate new messages to carry DOIC related information. Rather, they "piggyback" DOIC information over existing Diameter messages by inserting new AVPs into existing Diameter requests and responses. Nodes indicate support for DOIC, and any needed DOIC parameters by inserting an OC_Supported_Features AVP (Section 6.2) into existing requests and responses. Reporting nodes send OLRs by inserting OC-OLR AVPs (Section 6.3). A given OLR applies to the Diameter realm and application of the Diameter message that carries it. If a reporting node supports more than one realm and/or application, it reports independently for each combination of realm and application. Similarly, OC-Feature-Vector AVPs apply to the realm and application of the enclosing message. This implies that a node may support DOIC for one application and/or realm, but not another, and may indicate different DOIC parameters for each application and realm for which it supports DOIC. Reacting nodes perform overload abatement according to an agreed-upon abatement algorithm. An abatement algorithm defines the meaning of the parameters of an OLR, and the procedures required for overload abatement. This document specifies a single must-support algorithm, namely the "loss" algorithm Section 5). Future specifications may introduce new algorithms. Overload conditions may vary in scope. For example, a single Diameter node may be overloaded, in which case reacting nodes may reasonably attempt to send throttled requests to other destinations or via other agents. On the other hand, an entire Diameter realm may be overloaded, in which case such attempts would do harm. DOIC OLRs have a concept of "report type" (Section 6.6), where the type defines such behaviors. Report types are extensible. This document defines Korhonen, et al. Expires April 23, 2015 [Page 5] Internet-Draft DOIC October 2014 report types for overload of a specific server, and for overload of an entire realm. A report of type host is sent to indicate the overload of a specific server for the application-id indicated in the transaction. When receiving an OLR of type host, a reacting node applies overload abatement to what is referred to in this document as host-routed requests. This is the set of requests that the reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node. The reacting node applies overload abatement on those host-routed requests which the reacting node knows will be served by the server that matches the Origin-Host AVP of the received message that contained the received OLR of type host. A report type of realm is sent to indicate the overload of all servers in a realm for the application-id. When receiving an OLR of type realm, a reacting node applies overload abatement to what is referred to in this document as realm-routed requests. This is the set of requests that are not host-routed as defined in the previous paragraph. While a reporting node sends OLRs to "adjacent" reacting nodes, nodes that are "adjacent" for DOIC purposes may not be adjacent from a Diameter, or transport, perspective. For example, one or more Diameter agents that do not support DOIC may exist between a given pair of reporting and reacting nodes, as long as those agents pass unknown AVPs through unmolested. The report types described in this document can safely pass through non-supporting agents. This may not be true for report types defined in future specifications. Documents that introduce new report types MUST describe any limitations on their use across non-supporting agents. 3.1. Piggybacking Principle The overload control AVPs defined in this specification have been designed to be piggybacked on top of existing application message exchanges. This is made possible by adding overload control top level AVPs, the OC-OLR AVP and the OC-Supported-Features AVP as optional AVPs into existing commands when the corresponding Command Code Format (CCF) specification allows adding new optional AVPs (see Section 1.3.4 of [RFC6733]). Reacting nodes indicate support for DOIC by including the OC- Supported-Features AVP all request messages originated or relayed by the Diameter node. Korhonen, et al. Expires April 23, 2015 [Page 6] Internet-Draft DOIC October 2014 Reporting nodes indicate support for DOIC by including the OC- Supported-Features AVP in all answer messages originated or relayed by the Diameter node. Reporting nodes also include overload reports using the OC-OLR AVP in answer messages. Note: There is no new Diameter application defined to carry overload related AVPs. The DOIC AVPs are carried in existing Diameter application messages. Note that the overload control solution does not have fixed server and client roles. The DOIC node role is determined based on the message type: whether the message is a request (i.e. sent by a "reacting node") or an answer (i.e. send by a "reporting node"). Therefore, in a typical "client-server" deployment, the "client" MAY report its overload condition to the "server" for any server initiated message exchange. An example of such is the server requesting a re-authentication from a client. 3.2. DOIC Capability Announcement The DOIC solutions supports the ability for Diameter nodes to determine if other nodes in the path of a request support the solution. This capability is refered to as DOIC Capability Announcement (DCA) and is separate from Diameter Capability Exchange. The DCA mechanism is built around the piggybacking principle used for transporting Diameter overload AVPs. This includes both DCA AVPs and AVPs associated with Diameter overload reports. This allows for the DCA AVPs to be carried across Diameter nodes that do not support the DOIC solution. The DCA mechanism uses the OC-Supported-Features AVPs to indicate the Diameter overload features supported. The first node in the path of a Diameter request that supports the DOIC solution inserts the OC-Supported-Feature AVP in the request message. This includes an indication that it supports the loss overload abatement algorithm defined in this specification (see Section 5). This insures that there is at least one commonly supported overload abatement algorithm between the reporting node and the reacting nodes in the path of the request. DOIC must support deployments where Diameter Clients and/or Diameter servers do not support the DOIC solution. In this scenario, it is assumed that Diameter Agents that support the DOIC solution will handle overload abatement for the non supporting clients. In this case the DOIC agent will insert the OC- Supporting-Features AVP in requests that do not already contain Korhonen, et al. Expires April 23, 2015 [Page 7] Internet-Draft DOIC October 2014 one, telling the reporting node that there is a DOIC node that will handle overload abatement. The reporting node inserts the OC-Supported-Feature AVP in all answer messages to requests that contained the OC-Supported-Feature AVP. The contents of the reporting node's OC-Supported-Feature AVP indicate the set of Diameter overload features supported by the reporting node with one exception. The reporting node only includes an indication of support for one overload abatement algorithm. This is the algorithm that the reporting node intends to use should it enter an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports. Note that the loss algorithm defined in this document is a stateless abatement algorithm. As a result it does not require any actions by reacting nodes prior to the receipt of an overload report. Stateful abatement algorithms that base the abatement logic on a history of request messages sent might require reacting nodes to maintain state to insure that overload reports can be properly handled. The individual features supported by the DOIC nodes are indicated in the OC-Feature-Vector AVP. Any semantics associated with the features will be defined in extension specifications that introduce the features. The DCA mechanism must also support the scenario where the set of features supported by the sender of a request and by agents in the path of a request differ. In this case, the agent updates the OC- Supported-Feature AVP to reflect the mixture of the two sets of supported features. The logic to determine the content of the modified OC-Supported- Feature AVP is out-of-scope for this specification and is left to implementation decisions. Care must be taken in doing so not to introduce interoperability issues for downstream or upstream DOIC nodes. 3.3. DOIC Overload Condition Reporting As with DOIC Capability Announcement, Overload Condition Reporting uses new AVPs (Section 6.3) to indicate an overload condition. The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP includes the type of report, an overload report ID, the length of time that the report is valid and abatement algorithm specific AVPs. Korhonen, et al. Expires April 23, 2015 [Page 8] Internet-Draft DOIC October 2014 Two types of overload reports are defined in this document, host reports and realm reports. Host reports apply to traffic that is sent to a specific Diameter host. The applies to requests that contain the Destination-Host AVP that contains a DiameterIdentity that matches that of the overload report. These requests are referred to as host-routed requests. A host report also applies to realm-routed requests, requests that do not have a Destination-Host AVP, when the selected route for the request is a connection to the impacted host. Realm reports apply to realm-routed requests for a specific realm as indicated in the Destination-Realm AVP. Reporting nodes are responsible for determining the need for a reduction of traffic. The method for making this determination is implementation specific and depend on the type of overload report being generated. A host report, for instance, will generally be generated by tracking utilization of resources required by the host to handle transactions for the the Diameter application. A realm report will generally impact the traffic sent to multiple hosts and, as such, will typically require tracking the capacity of the servers able to handle realm-routed requests for the application. Once a reporting node determines the need for a reduction in traffic, it uses the DOIC defined AVPs to report on the condition. These AVPs are included in answer messages sent or relayed by the reporting node. The reporting node indicates the overload abatement algorithm that is to be used to handle the traffic reduction in the OC- Supported-Features AVP. The OC-OLR AVP is used to communicate information about the requested reduction. Reacting nodes, upon receipt of an overload report, are responsible for applying the abatement algorithm to traffic impacted by the overload report. The method used for that abatement is dependent on the abatement algorithm. The loss abatement algorithm is defined in this document (Section 5). Other abatement algorithms can be defined in extensions to the DOIC solutions. As the conditions that lead to the generation of the overload report change the reporting node can send new overload reports requesting greater reduction if the condition gets worse or less reduction if the condition improves. The reporting node sends an overload report with a duration of zero to indicate that the overlaod condition has ended and use of the abatement algorithm is no longer needed. Korhonen, et al. Expires April 23, 2015 [Page 9] Internet-Draft DOIC October 2014 The reacting node also determines when the overload report expires based on the OC-Validaty-Duration AVP in the overload report and stops applying the abatement algorithm when the report expires. 3.4. DOIC Extensibility The DOIC solutions is designed to be extensible. This extensibility is based on existing Diameter based extensibility mechanisms. There are multiple categories of extensions that are expected. This includes the definition of new overload abatement algorithms, the definition of new report types and new definitions of the scope of messages impacted by an overload report. The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes to communicate supported features. The specific features supported by the DOIC node are indicated in the OC-Feature-Vector AVP. DOIC extensions must define new values for the OC-Feature-Vector AVP. DOIC extensions also have the ability to add new AVPs to the OC- Supported-Features AVP, if additional information about the new feature is required to be communicate. Overload abatement algorithms use the OC-OLR AVP to communicate overload occurances. This AVP can also be extended to add new AVPs allowing a reporting nodes to communicate additional information about handling an overload condition. If necessary, new extensions can also define new top level AVPs. It is, however, recommended that DOIC extensions use the OC-Supported- Features and OC-OLR to carry all DOIC related AVPs. 3.5. Simplified Example Architecture Figure 1 illustrates the simplified architecture for Diameter overload information conveyance. Korhonen, et al. Expires April 23, 2015 [Page 10] Internet-Draft DOIC October 2014 Realm X Same or other Realms <--------------------------------------> <----------------------> +--^-----+ : (optional) : |Diameter| : : |Server A|--+ .--. : +---^----+ : .--. +--------+ | _( `. : |Diameter| : _( `. +---^----+ +--( )--:-| Agent |-:--( )--|Diameter| +--------+ | ( ` . ) ) : +-----^--+ : ( ` . ) ) | Client | |Diameter|--+ `--(___.-' : : `--(___.-' +-----^--+ |Server B| : : +---^----+ : : End-to-end Overload Indication 1) <-----------------------------------------------> Diameter Application Y Overload Indication A Overload Indication A' 2) <----------------------> <----------------------> standard base protocol standard base protocol Figure 1: Simplified architecture choices for overload indication delivery In Figure 1, the Diameter overload indication can be conveyed (1) end-to-end between servers and clients or (2) between servers and Diameter agent inside the realm and then between the Diameter agent and the clients when the Diameter agent acting as back-to-back-agent for DOIC purposes. 4. Solution Procedures This section outlines the normative behavior associated with the DOIC solution. 4.1. Capability Announcement This section defines DOIC Capability Announcement (DCA) behavior. The DCA procedures are used to indicate support for DOIC and support for DOIC features. The DOIC features include overload abatement algorithms supported. It might also include new report types or other extensions documented in the future. Korhonen, et al. Expires April 23, 2015 [Page 11] Internet-Draft DOIC October 2014 Diameter nodes indicate support for DOIC by including the OC- Supported-Features AVP in messages sent or handled by the node. Diameter agents that support DOIC MUST ensure that all messages have the OC-Supporting-Features AVP. If a message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP. If the message already has the AVP then the agent either leaves it unchanged in the relayed message or modifies it to reflect a mixed set of DOIC features. 4.1.1. Reacting Node Behavior A reacting node MUST include the OC-Supported-Features AVP in all request messages. A reacting node MAY include the OC-Feature-Vector AVP with an indication of the loss algorithm. A reacting node MUST include the OC-Feature-Vector AVP to indicate support for abatement algorithms in addition to the loss algorithm. A reacting node SHOULD indicate support for all other DOIC features it supports. An OC-Supported-Features AVP in answer messages indicates there is a reporting node for the transaction. The reacting node MAY take action based on the features indicated in the OC-Feature-Vector AVP. Note that the loss abatement algorithm is the only feature described in this document and it does not require action to be taken when there is an active overload report. This behavior is described in Section 4.2 and Section 5. 4.1.2. Reporting Node Behavior Upon receipt of a request message, a reporting node determines if there is a reacting node for the transaction based on the presence of the OC-Supported-Features AVP. Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality supported by reacting node(s). The reporting node then acts accordingly for the subsequent answer messages it initiates. If the reqeust message contains an OC-Supported-Features AVP then the reporting node MUST include the OC-Supported-Features AVP in the answer message for that transaction. Korhonen, et al. Expires April 23, 2015 [Page 12] Internet-Draft DOIC October 2014 The reporting node MUST indicate support for one and only one abatement algorithm in the OC-Feature-Vector AVP. The abatement algorithm included MUST be from the set of abatement algorithms contained in the request messages OC-Supported-Features AVP. The abatement algorithm included indicates the abatement algorithm the reporting node wants the reacting node to use when the reporting node enters an overload condition. The reporting node MUST NOT change the selected algorithm during a period of time that it is in an overload condition and, as a result, is sending OC-OLR AVPs in answer messages. The reporting node SHOULD indicate support for other DOIC features it supports and that apply to the transaction. Note that not all DOIC features will apply to all Diameter applications or deployment scenarios. The features included in the OC-Feature-Vector AVP is based on local reporting node policy. The reporting node MUST NOT include the OC-Supported-Features AVP, OC-OLR AVP or any other overload control AVPs defined in extension drafts in response messages for transactions where the request message does not include the OC-Supported-Features AVP. Lack of the OC-Supported-Features AVP in the request message indicates that there is no reacting node for the transaction. An agent MAY modify the OC-Supported-Features AVP carried in answer messages. 4.2. Overload Report Processing 4.2.1. Overload Control State Both reacting and reporting nodes maintain an overload control state (OCS) for active overload reports. 4.2.1.1. Overload Control State for Reacting Nodes A reacting node maintains the following OCS per supported Diameter application: o A host-type Overload Control State for each Destination-Host towards which it sends host-type requests and o A realm-type Overload Control State for each Destination-Realm towards which it sends realm-type requests. Korhonen, et al. Expires April 23, 2015 [Page 13] Internet-Draft DOIC October 2014 A host-type Overload Control State may be identified by the pair of Application-Id and Destination-Host. A realm-type Overload Control State may be identified by the pair of Application-Id and Destination-Realm. The host-type/realm-type Overload Control State for a given pair of Application and Destination-Host / Destination- Realm could include the following information: o Sequence number (as received in OC-OLR) o Time of expiry (deviated from validity duration as received in OC- OLR and time of reception) o Selected Abatement Algorithm (as received in OC-Supported- Features) o Algorithm specific input data (as received within OC-OLR, e.g. Reduction Percentage for Loss) 4.2.1.2. Overload Control States for Reporting Nodes A reporting node maintains per supported Diameter application and per supported (and eventually selected) Abatement Algorithm an Overload Control State. An Overload Control State may be identified by the pair of Application-Id and supported Abatement Algorithm. The Overload Control State for a given pair of Application and Abatement Algorithm could include the information: o Report type o Sequence number o Validity Duration and Expiry Time o Algorithm specific input data (e.g. Reduction Percentage for Loss) 4.2.1.3. Maintaining Overload Control State Reacting nodes create a host-type OCS identified by OCS-Id = (app- id,host-id) when receiving an answer message of application app-id containing an Orig-Host of host-id and a host-type OC-OLR AVP unless such host-type OCS already exists. Reacting nodes create a realm-type OCS identified by OCS-Id = (app- id,realm-id) when receiving an answer message of application app-id Korhonen, et al. Expires April 23, 2015 [Page 14] Internet-Draft DOIC October 2014 containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP unless such realm type OCS already exists. Reacting nodes delete an OCS when it expires (i.e. when current time minus reception time is greater than validity duration). Reacting nodes also delete on OCS with an updated OLR is received with a validity duration of zero. Reacting nodes update the host-type OCS identified by OCS-Id = (app- id,host-id) when receiving an answer message of application app-id containing an Orig-Host of host-id and a host-type OC-OLR AVP with a sequence number higher than the stored sequence number. Reacting nodes update the realm-type OCS identified by OCS-Id = (app- id,realm-id) when receiving an answer message of application app-id containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP with a sequence number higher than the stored sequence number. Reacting nodes do not delete an OCS when receiving an answer message that does not contain an OC-OLR AVP (i.e. absence of OLR means "no change"). Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a request of application app-id containing an OC- Supported-Features AVP indicating support of the Abatement Algorithm Alg (which the reporting node selects) while being overloaded, unless such OCS already exists. Reporting nodes delete an OCS when it expires. Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the need to modify the requested amount of application app-id traffic reduction. 4.2.2. Reacting Node Behavior Once a reacting node receives an OC-OLR AVP from a reporting node, it applies traffic abatement based on the selected algorithm with the reporting node and the current overload condition. The reacting node learns the reporting node supported abatement algorithms directly from the received answer message containing the OC-Supported-Features AVP. The received OC-Supported-Features AVP does not change the existing overload condition and/or traffic abatement algorithm settings if the OC-Sequence-Number AVP contains a value that is equal to the previously received/recorded value. If the OC-Supported-Features AVP Korhonen, et al. Expires April 23, 2015 [Page 15] Internet-Draft DOIC October 2014 is received for the first time for the reporting node or the OC- Sequence-Number AVP value is less than the previously received/ recorded value (and is outside the valid overflow window), then the sequence number is stale (e.g. an intentional or unintentional replay) and SHOULD be silently discarded. As described in Section 6.3, the OC-OLR AVP contains the necessary information for the overload condition on the reporting node. From the OC-Report-Type AVP contained in the OC-OLR AVP, the reacting node learns whether the overload condition report concerns a specific host (as identified by the Origin-Host AVP of the answer message containing the OC-OLR AVP) or the entire realm (as identified by the Origin-Realm AVP of the answer message containing the OC-OLR AVP). The reacting node learns the Diameter application to which the overload report applies from the Application-ID of the answer message containing the OC-OLR AVP. The reacting node MUST use this information as an input for its traffic abatement algorithm. The idea is that the reacting node applies different handling of the traffic abatement, whether sent request messages are targeted to a specific host (identified by the Diameter-Host AVP in the request) or to any host in a realm (when only the Destination-Realm AVP is present in the request). Note that future specifications MAY define new OC-Report-Type AVP values that imply different handling of the OC-OLR AVP. For example, in a form of new additional AVPs inside the Grouped OC-OLR AVP that would define report target in a finer granularity than just a host. If the OC-OLR AVP is received for the first time, the reacting node MUST create overload control state associated with the related realm or a specific host in the realm identified in the message carrying the OC-OLR AVP, as described in Section 4.2.1. If the value of the OC-Sequence-Number AVP contained in the received OC-OLR AVP is equal to or less than the value stored in an existing overload control state, the received OC-OLR AVP SHOULD be silently discarded. If the value of the OC-Sequence-Number AVP contained in the received OC-OLR AVP is greater than the value stored in an existing overload control state or there is no previously recorded sequence number, the reacting node MUST update the overload control state associated with the realm or the specific node in the realm. When an overload control state is created or updated, the reacting node MUST apply the traffic abatement requested in the OC-OLR AVP using the algorithm announced in the OC-Supported-Features AVP contained in the received answer message along with the OC-OLR AVP. Korhonen, et al. Expires April 23, 2015 [Page 16] Internet-Draft DOIC October 2014 The validity duration of the overload information contained in the OC-OLR AVP is either explicitly indicated in the OC-Validity-Duration AVP or is implicitly equals to the default value if the OC-Validity- Duration AVP is absent. The reacting node MUST maintain the validity duration in the overload control state. Once the validity duration times out, the reacting node MUST assume the overload condition reported in a previous OC-OLR AVP has ended. A value of zero ("0") received in the OC-Validity-Duration in an updated overload report indicates that the overload condition has ended and that the overload state is no longer valid. In the case that the validity duration expires or is explicitly signaled as being no longer valid the state associated with the overload report MUST be removed and any abatement associated with the overload report MUST be ended in a controlled fashion. After removing the overload state the sequence number MUST NOT be used for future comparisons of sequence numbers. 4.2.3. Reporting Node Behavior A reporting node is a Diameter node inserting an OC-OLR AVP in a Diameter message in order to inform a reacting node about an overload condition and request Diameter traffic abatement. The operation on the reporting node is straight forward. The reporting node learns the capabilities of the reacting node when it receives the OC-Supported-Features AVP as part of any Diameter request message. Since the loss abatement algorithm Section 5 is mandatory to implement DOIC can always be enabled between these DOIC nodes See Section 4.1 for further discussion on the capability and feature announcement. When a traffic reduction is required due to an overload condition and the overload control solution is supported by the sender of the Diameter request, the reporting node SHOULD include an OC-Supported- Features AVP and an OC-OLR AVP in the corresponding Diameter answer. A reporting node MAY choose to not resend an overload report to a reacting node if it can guarantee that this overload report is already active in the reacting node. Note - In some cases (e.g. when there are one or multiple agents in the path between reporting and reacting nodes, or when overload reports are discarded by reacting nodes) the reporting node may not be able to guarantee that the reacting node has received the report. Korhonen, et al. Expires April 23, 2015 [Page 17] Internet-Draft DOIC October 2014 The OC-OLR AVP contains the required traffic reduction and the OC- Supported-Features AVP indicates the traffic abatement algorithm to apply. This algorithm MUST be one of the algorithms advertised by the request sender. A reporting node MUST only send overload reports of a type advertised as supported by the reacting node. Note that a reacting node advertises support for the host and realm report types by including the OC-Supported-Features AVP in the request. Support for other report types must be explicitly indicated by a new feature bit in the OC-Feature-Vector AVP. If OLR is for a new overload condition and there is no unexpired overload report for previous overload conditions at any reacting node then the reporting node MAY set the sequence number to any value. The reacting node MAY update the overload report with new reduction percentages. When doing so, the reacting node MUST increase the sequence number in the new OLR sent. When generating sequence numbers for , the new sequence number MUST be greater than any sequence number in an active (unexpired) overload report previously sent by the reporting node. This property MUST hold over a reboot of the reporting node. A reporting node MAY rely on the OC-Validity-Duration AVP values for the implicit overload control state cleanup on the reacting node. However, it is RECOMMENDED that the reporting node always explicitly indicates the end of a overload condition. The reporting node SHOULD indicate the end of an overload occurrence by sending a new OLR with OC-Validity-Duration set to a value of zero ("0"). The reporting node SHOULD insure that all reacting nodes receive the updated overload report. All OLRs sent have an expiration time calculated by adding the validity-duration contained in the OLR to the time the message was sent. Transit time for the OLR can be safely ignored. The reporting node can ensure that all reacting nodes have received the OLR by continuing to send it in answer messages until the expiration time for all OLRs sent for that overload contition have expired. Korhonen, et al. Expires April 23, 2015 [Page 18] Internet-Draft DOIC October 2014 4.3. Protocol Extensibility The overload control solution can be extended, e.g. with new traffic abatement algorithms, new report types or other new functionality. When defining a new extension a new feature bit MUST be defined for the OC-Feature-Vector. This feature bit is used to communicate support for the new feature. The extention may also define new AVPs for use in DOIC Capability Anouncement and for use in DOIC Overload reporting. These new AVP should be defined to be extensions to the OC-Supported-Features and OC-OLR AVPs defined in this document. It should be noted that [RFC6733] defined Grouped AVP extension mechanisms apply. This allows, for example, defining a new feature that is mandatory to be understood even when piggybacked on an existing applications. The handling of feature bits in the OC-Feature-Vector AVP that are not associated with overload abatement algorithms MUST be specified by the extensions that define the features. When defining new report type values, the corresponding specification MUST define the semantics of the new report types and how they affect the OC-OLR AVP handling. The specification MUST also reserve a corresponding new feature, see the OC-Supported-Features and OC- Feature-Vector AVPs. The OC-OLR AVP can be expanded with optional sub-AVPs only if a legacy implementation can safely ignore them without breaking backward compatibility for the given OC-Report-Type AVP value implied report handling semantics. If the new sub-AVPs imply new semantics for handling the indicated report type, then a new OC-Report-Type AVP value MUST be defined. New features (feature bits in the OC-Feature-Vector AVP) and report types (in the OC-Report-Type AVP) MUST be registered with IANA. As with any Diameter specification, new AVPs MUST also be registered with IANA. See Section 8 for the required procedures. 5. Loss Algorithm This section documents the Diameter overload loss abatement algorithm. Korhonen, et al. Expires April 23, 2015 [Page 19] Internet-Draft DOIC October 2014 5.1. Overview The DOIC specification supports the ability for multiple overload abatement algorithms to be specified. The abatement algorithm used for any instance of overload is determined by the Diameter Overload Capability Announcement process documented in Section 4.1. The loss algorithm described in this section is the default algorithm that must be supported by all Diameter nodes that support DOIC. The loss algorithm is designed to be a straightforward and stateless overload abatement algorithm. It is used by reporting nodes to request a percentage reduction in the amount of traffic sent. The traffic impacted by the requested reduction depends on the type of overload report. Reporting nodes use a strategy of applying abatement logic to the requested percentage of request messages sent (or handled in the case of agents) by the reacting node that are impacted by the overload report. From a conceptual level, the logic at the reacting node could be outlined as follows. In this discussion assume that the reacting node is also the sending node. 1. An overload report is received and the associated overload state is saved by the reacting node. 2. A new Diameter request is generated by the application running on the reacting node. 3. The reacting node determines that an active overload report applies to the request. 4. The reacting node determines if abatement should be applied to the request. One approach that could be taken would be to select a random number between 1 and 100. If the random number is less than the indicated reduction percentage then the request is given abatement treatment, otherwise the request is given normal routing treatment. 5.2. Reporting Node Behavior The method a reporting nodes uses to determine the amount of traffic reduction required to address an overload condition is an implementation decision. Korhonen, et al. Expires April 23, 2015 [Page 20] Internet-Draft DOIC October 2014 When a reporting node that has selected the loss abatement algorithm determines the need to request a traffic reduction it includes an OC- OLR AVP in response messages as described in Section 4.2.3. The reporting node must indicate a percentage reduction in the OC- Reduction-Percentage AVP. The reporting node may change the reduction percentage in subsequent overload reports. When doing so the reporting node must conform to overload report handing specified in Section 4.2.3. When the reporting node determines it no longer needs a reduction in traffic the reporting node should send an overload report indicating the overload report is no longer valid, as specified in Section 4.2.3. 5.3. Reacting Node Behavior The method a reacting node uses to determine which request messages are given abatement treatment is an implementation decision. When receiving an OC-OLR in an answer message where the algorithm indicated in the OC-Supported-Features AVP is the loss algorithm, the reacting node must attempt to apply abatement treatment to the requested percentage of request messages sent. Note: the loss algorithm is a stateless algorithm. As a result, the reacting node does not guarantee that there will be an absolute reduction in traffic sent. Rather, it guarantees that the requested percentage of new requests will be given abatement treatment. If reacting node comes out of the 100 percent traffic reduction as a result of the overload report timing out, the following concerns are RECOMMENDED to be applied. The reacting node sending the traffic should be conservative and, for example, first send "probe" messages to learn the overload condition of the overloaded node before converging to any traffic amount/rate decided by the sender. Similar concerns apply in all cases when the overload report times out unless the previous overload report stated 0 percent reduction. If the reacting node does not receive a an OLR in messages sent to the formally overloaded node then the reacting node should slowly increase the rate of traffic sent to the overloaded node. It is suggested that the reacting node decrease the amount of traffic given abatement treatment by 20% each second until the reduction is completely removed and no traffic is given abatement treatment. Korhonen, et al. Expires April 23, 2015 [Page 21] Internet-Draft DOIC October 2014 The goal of this behavior is to reduce the probability of overload condition thrashing where an immediate transition from 100% reduction to 0% reduction results in the reporting node moving quickly back into an overload condition. 6. Attribute Value Pairs This section describes the encoding and semantics of the Diameter Overload Indication Attribute Value Pairs (AVPs) defined in this document. When added to existing commands, both OC-Feature-Vector and OC-OLR AVPs SHOULD have the M-bit flag cleared to avoid backward compatibility issues. A new application specification can incorporate the overload control mechanism specified in this document by making it mandatory to implement for the application and referencing this specification normatively. In such a case, the rules for handling of the M-bit must follow the guidance in [RFC6733]. It is the responsibility of the Diameter application designers to define how overload control mechanisms works on that application. 6.1. OC-Supported-Features AVP The OC-Supported-Features AVP (AVP code TBD1) is type of Grouped and serves two purposes. First, it announces a node's support for the DOIC solution in general. Second, it contains the description of the supported DOIC features of the sending node. The OC-Supported- Features AVP MUST be included in every Diameter message a DOIC supporting node sends. OC-Supported-Features ::= < AVP Header: TBD1 > [ OC-Feature-Vector ] * [ AVP ] The OC-Feature-Vector sub-AVP is used to announce the DOIC features supported by the DOIC node, in the form of a flag bits field in which each bit announces one feature or capability supported by the node (see Section 6.2). The absence of the OC-Feature-Vector AVP indicates that only the default traffic abatement algorithm described in this specification is supported. Korhonen, et al. Expires April 23, 2015 [Page 22] Internet-Draft DOIC October 2014 6.2. OC-Feature-Vector AVP The OC-Feature-Vector AVP (AVP code TBD6) is type of Unsigned64 and contains a 64 bit flags field of announced capabilities of a DOIC node. The value of zero (0) is reserved. The following capabilities are defined in this document: OLR_DEFAULT_ALGO (0x0000000000000001) When this flag is set by the DOIC node it means that the default traffic abatement (loss) algorithm is supported. 6.3. OC-OLR AVP The OC-OLR AVP (AVP code TBD2) is type of Grouped and contains the information necessary to convey an overload report. The OC-OLR AVP does not explicitly contain all information needed by the reacting node to decide whether a subsequent request must undergo a throttling process with the received reduction percentage. The value of the OC- Report-Type AVP within the OC-OLR AVP indicates which implicit information is relevant for this decision (see Section 6.6). The application the OC-OLR AVP applies to is the same as the Application- Id found in the Diameter message header. The host or realm the OC- OLR AVP concerns is determined from the Origin-Host AVP and/or Origin-Realm AVP found in the encapsulating Diameter command. The OC-OLR AVP is intended to be sent only by a reporting node. OC-OLR ::= < AVP Header: TBD2 > < OC-Sequence-Number > < OC-Report-Type > [ OC-Reduction-Percentage ] [ OC-Validity-Duration ] * [ AVP ] Note that if a Diameter command were to contain multiple OC-OLR AVPs they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs with unknown values SHOULD be silently discarded and the event SHOULD be logged. 6.4. OC-Sequence-Number AVP The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64. Its usage in the context of overload control is described in Section 4.2. Korhonen, et al. Expires April 23, 2015 [Page 23] Internet-Draft DOIC October 2014 From the functionality point of view, the OC-Sequence-Number AVP MUST be used as a non-volatile increasing counter for a sequence of overload reports between two DOIC nodes for the same overload occurrence. The sequence number is only required to be unique between two DOIC nodes. Sequence numbers are treated in a uni- directional manner, i.e. two sequence numbers on each direction between two DOIC nodes are not related or correlated. When generating sequence numbers, the new sequence number MUST be greater than any sequence number in an active, unexpired, overload report previously sent by the reporting node. This property MUST hold over a reboot of the reporting node. 6.5. OC-Validity-Duration AVP The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and indicates in seconds the validity time of the overload report. The number of seconds is measured after reception of the first OC-OLR AVP with a given value of OC-Sequence-Number AVP. The default value for the OC-Validity-Duration AVP is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. Validity duration with values above 86400 (i.e.; 24 hours) MUST NOT be used. Invalid duration values are treated as if the OC-Validity-Duration AVP were not present and result in the default value being used. A timeout of the overload report has specific concerns that need to be taken into account by the DOIC node acting on the earlier received overload report(s). Section 6.7 discusses the impacts of timeout in the scope of the traffic abatement algorithms. When a reporting node has recovered from overload, it SHOULD invalidate any existing overload reports in a timely matter. This can be achieved by sending an updated overload report (meaning the OLR contains a new sequence number) with the OC-Validity-Duration AVP value set to zero ("0"). If the overload report is about to expire naturally, the reporting node MAY choose to simply let it do so. A reacting node MUST invalidate and remove an overload report that expires without an explicit overload report containing an OC- Validity-Duration value set to zero ("0"). 6.6. OC-Report-Type AVP The OC-Report-Type AVP (AVP code TBD5) is type of Enumerated. The value of the AVP describes what the overload report concerns. The following values are initially defined: Korhonen, et al. Expires April 23, 2015 [Page 24] Internet-Draft DOIC October 2014 0 A host report. The overload treatment should apply to requests for which all of the following conditions are true: Either the Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP; or the Destination-Host is not present in the request but the value of peer identity associated with the connection used to send the request matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. 1 A realm report. The overload treatment should apply to requests for which all of the following conditions are true: The Destination-Host AVP is absent in the request. The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. The OC-Report-Type AVP is envisioned to be useful for situations where a reacting node needs to apply different overload treatments for different "types" of overload. For example, the reacting node(s) might need to throttle differently requests sent to a specific server (identified by the Destination-Host AVP in the request) and requests that can be handled by any server in a realm. 6.7. OC-Reduction-Percentage AVP The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32 and describes the percentage of the traffic that the sender is requested to reduce, compared to what it otherwise would send. The OC-Reduction-Percentage AVP applies to the default (loss) algorithm specified in this specification. However, the AVP can be reused for future abatement algorithms, if its semantics fit into the new algorithm. Korhonen, et al. Expires April 23, 2015 [Page 25] Internet-Draft DOIC October 2014 The value of the Reduction-Percentage AVP is between zero (0) and one hundred (100). Values greater than 100 are ignored. The value of 100 means that all traffic is to be throttled, i.e. the reporting node is under a severe load and ceases to process any new messages. The value of 0 means that the reporting node is in a stable state and has no need for the reacting node to apply any traffic abatement. The default value of the OC-Reduction-Percentage AVP is 0. When the OC-Reduction-Percentage AVP is not present in the overload report, the default value applies. 6.8. Attribute Value Pair flag rules +---------+ |AVP flag | |rules | +----+----+ AVP Section | |MUST| Attribute Name Code Defined Value Type |MUST| NOT| +--------------------------------------------------+----+----+ |OC-Supported-Features TBD1 x.x Grouped | | V | +--------------------------------------------------+----+----+ |OC-OLR TBD2 x.x Grouped | | V | +--------------------------------------------------+----+----+ |OC-Sequence-Number TBD3 x.x Unsigned64 | | V | +--------------------------------------------------+----+----+ |OC-Validity-Duration TBD4 x.x Unsigned32 | | V | +--------------------------------------------------+----+----+ |OC-Report-Type TBD5 x.x Enumerated | | V | +--------------------------------------------------+----+----+ |OC-Reduction | | | | -Percentage TBD8 x.x Unsigned32 | | V | +--------------------------------------------------+----+----+ |OC-Feature-Vector TBD6 x.x Unsigned64 | | V | +--------------------------------------------------+----+----+ As described in the Diameter base protocol [RFC6733], the M-bit setting for a given AVP is relevant to an application and each command within that application that includes the AVP. The Diameter overload control AVPs SHOULD always be sent with the M-bit cleared when used within existing Diameter applications to avoid backward compatibility issues. Otherwise, when reused in newly defined Diameter applications, the DOC related AVPs SHOULD have the M-bit set. Korhonen, et al. Expires April 23, 2015 [Page 26] Internet-Draft DOIC October 2014 7. Error Response Codes Editor's note: This section depends on resolution of issue #27. 8. IANA Considerations 8.1. AVP codes New AVPs defined by this specification are listed in Section 6. All AVP codes allocated from the 'Authentication, Authorization, and Accounting (AAA) Parameters' AVP Codes registry. 8.2. New registries Three new registries are needed under the 'Authentication, Authorization, and Accounting (AAA) Parameters' registry. Section 6.2 defines a new "Overload Control Feature Vector" registry including the initial assignments. New values can be added into the registry using the Specification Required policy [RFC5226]. See Section 6.2 for the initial assignment in the registry. Section 6.6 defines a new "Overload Report Type" registry with its initial assignments. New types can be added using the Specification Required policy [RFC5226]. 9. Security Considerations This mechanism gives Diameter nodes the ability to request that downstream nodes send fewer Diameter requests. Nodes do this by exchanging overload reports that directly affect this reduction. This exchange is potentially subject to multiple methods of attack, and has the potential to be used as a Denial-of-Service (DoS) attack vector. Overload reports may contain information about the topology and current status of a Diameter network. This information is potentially sensitive. Network operators may wish to control disclosure of overload reports to unauthorized parties to avoid its use for competitive intelligence or to target attacks. Diameter does not include features to provide end-to-end authentication, integrity protection, or confidentiality. This may cause complications when sending overload reports between non- adjacent nodes. Korhonen, et al. Expires April 23, 2015 [Page 27] Internet-Draft DOIC October 2014 9.1. Potential Threat Modes The Diameter protocol involves transactions in the form of requests and answers exchanged between clients and servers. These clients and servers may be peers, that is,they may share a direct transport (e.g. TCP or SCTP) connection, or the messages may traverse one or more intermediaries, known as Diameter Agents. Diameter nodes use TLS, DTLS, or IPSec to authenticate peers, and to provide confidentiality and integrity protection of traffic between peers. Nodes can make authorization decisions based on the peer identities authenticated at the transport layer. When agents are involved, this presents an effectively hop-by-hop trust model. That is, a Diameter client or server can authorize an agent for certain actions, but it must trust that agent to make appropriate authorization decisions about its peers, and so on. Since confidentiality and integrity protection occurs at the transport layer. Agents can read, and perhaps modify, any part of a Diameter message, including an overload report. There are several ways an attacker might attempt to exploit the overload control mechanism. An unauthorized third party might inject an overload report into the network. If this third party is upstream of an agent, and that agent fails to apply proper authorization policies, downstream nodes may mistakenly trust the report. This attack is at least partially mitigated by the assumption that nodes include overload reports in Diameter answers but not in requests. This requires an attacker to have knowledge of the original request in order to construct a response. Therefore, implementations SHOULD validate that an answer containing an overload report is a properly constructed response to a pending request prior to acting on the overload report. A similar attack involves an otherwise authorized Diameter node that sends an inappropriate overload report. For example, a server for the realm "example.com" might send an overload report indicating that a competitor's realm "example.net" is overloaded. If other nodes act on the report, they may falsely believe that "example.net" is overloaded, effectively reducing that realm's capacity. Therefore, it's critical that nodes validate that an overload report received from a peer actually falls within that peer's responsibility before acting on the report or forwarding the report to other peers. For example, an overload report from an peer that applies to a realm not handled by that peer is suspect. An attacker might use the information in an overload report to assist in certain attacks. For example, an attacker could use information Korhonen, et al. Expires April 23, 2015 [Page 28] Internet-Draft DOIC October 2014 about current overload conditions to time a DoS attack for maximum effect, or use subsequent overload reports as a feedback mechanism to learn the results of a previous or ongoing attack. 9.2. Denial of Service Attacks Diameter overload reports can cause a node to cease sending some or all Diameter requests for an extended period. This makes them a tempting vector for DoS tacks. Furthermore, since Diameter is almost always used in support of other protocols, a DoS attack on Diameter is likely to impact those protocols as well. Therefore, Diameter nodes MUST NOT honor or forward overload reports from unauthorized or otherwise untrusted sources. 9.3. Non-Compliant Nodes When a Diameter node sends an overload report, it cannot assume that all nodes will comply. A non-compliant node might continue to send requests with no reduction in load. Requirement 28 [RFC7068] indicates that the overload control solution cannot assume that all Diameter nodes in a network are necessarily trusted, and that malicious nodes not be allowed to take advantage of the overload control mechanism to get more than their fair share of service. In the absence of an overload control mechanism, Diameter nodes need to implement strategies to protect themselves from floods of requests, and to make sure that a disproportionate load from one source does not prevent other sources from receiving service. For example, a Diameter server might reject a certain percentage of requests from sources that exceed certain limits. Overload control can be thought of as an optimization for such strategies, where downstream nodes never send the excess requests in the first place. However, the presence of an overload control mechanism does not remove the need for these other protection strategies. 9.4. End-to End-Security Issues The lack of end-to-end security features makes it far more difficult to establish trust in overload reports that originate from non- adjacent nodes. Any agents in the message path may insert or modify overload reports. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive-trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting Diameter overload control MUST give operators the ability to select which peers are trusted to deliver overload Korhonen, et al. Expires April 23, 2015 [Page 29] Internet-Draft DOIC October 2014 reports, and whether they are trusted to forward overload reports from non-adjacent nodes. The lack of end-to-end confidentiality protection means that any Diameter agent in the path of an overload report can view the contents of that report. In addition to the requirement to select which peers are trusted to send overload reports, operators MUST be able to select which peers are authorized to receive reports. A node MUST not send an overload report to a peer not authorized to receive it. Furthermore, an agent MUST remove any overload reports that might have been inserted by other nodes before forwarding a Diameter message to a peer that is not authorized to receive overload reports. At the time of this writing, the DIME working group is studying requirements for adding end-to-end security [I-D.ietf-dime-e2e-sec-req] features to Diameter. These features, when they become available, might make it easier to establish trust in non-adjacent nodes for overload control purposes. Readers should be reminded, however, that the overload control mechanism encourages Diameter agents to modify AVPs in, or insert additional AVPs into, existing messages that are originated by other nodes. If end-to-end security is enabled, there is a risk that such modification could violate integrity protection. The details of using any future Diameter end-to-end security mechanism with overload control will require careful consideration, and are beyond the scope of this document. 10. Contributors The following people contributed substantial ideas, feedback, and discussion to this document: o Eric McMurry o Hannes Tschofenig o Ulrich Wiehe o Jean-Jacques Trottin o Maria Cruz Bartolome o Martin Dolly o Nirav Salot o Susan Shishufeng Korhonen, et al. Expires April 23, 2015 [Page 30] Internet-Draft DOIC October 2014 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012. 11.2. Informative References [Cx] 3GPP, , "ETSI TS 129 229 V11.4.0", August 2013. [I-D.ietf-dime-e2e-sec-req] Tschofenig, H., Korhonen, J., Zorn, G., and K. Pillay, "Diameter AVP Level Security: Scenarios and Requirements", draft-ietf-dime-e2e-sec-req-00 (work in progress), September 2013. [PCC] 3GPP, , "ETSI TS 123 203 V11.12.0", December 2013. [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005. [RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009. [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control Requirements", RFC 7068, November 2013. [S13] 3GPP, , "ETSI TS 129 272 V11.9.0", December 2012. Appendix A. Issues left for future specifications The base solution for the overload control does not cover all possible use cases. A number of solution aspects were intentionally left for future specification and protocol work. Korhonen, et al. Expires April 23, 2015 [Page 31] Internet-Draft DOIC October 2014 A.1. Additional traffic abatement algorithms This specification describes only means for a simple loss based algorithm. Future algorithms can be added using the designed solution extension mechanism. The new algorithms need to be registered with IANA. See Sections 6.1 and 8 for the required IANA steps. A.2. Agent Overload This specification focuses on Diameter endpoint (server or client) overload. A separate extension will be required to outline the handling the case of agent overload. A.3. DIAMETER_TOO_BUSY clarifications The current [RFC6733] behavior in a case of DIAMETER_TOO_BUSY is somewhat under specified. For example, there is no information how long the specific Diameter node is willing to be unavailable. A specification updating [RFC6733] should clarify the handling of DIAMETER_TOO_BUSY from the error answer initiating Diameter node point of view and from the original request initiating Diameter node point of view. Further, the inclusion of possible additional information providing AVPs should be discussed and possible be recommended to be used. Appendix B. Deployment Considerations Non supporting agents Due to the way that realm-routed requests are handled in Diameter networks, with the server selection for the request done by an agent, it is recommended that deployments upgrade all agents with direct connections to servers prior to enabling the DOIC solution in the Diameter network. Topology hiding interactions There exist proxies that implement what is refered to as Topology Hiding. This can include cases where the agent modifies the Origin-Host in answer messages. The behavior of the DOIC solution is not well understood when this happens. As such, the DOIC solution does not address this scenario. Korhonen, et al. Expires April 23, 2015 [Page 32] Internet-Draft DOIC October 2014 Appendix C. Considerations for Applications Integrating the DOIC Solution THis section outlines considerations to be taken into account when integrating the DOIC solution into Diameter applications. C.1. Application Classification The following is a classification of Diameter applications and requests. This discussion is meant to document factors that play into decisions made by the Diameter identity responsible for handling overload reports. Section 8.1 of [RFC6733] defines two state machines that imply two types of applications, session-less and session-based applications. The primary difference between these types of applications is the lifetime of Session-Ids. For session-based applications, the Session-Id is used to tie multiple requests into a single session. In session-less applications, the lifetime of the Session-Id is a single Diameter transaction, i.e. the session is implicitly terminated after a single Diameter transaction and a new Session-Id is generated for each Diameter request. For the purposes of this discussion, session-less applications are further divided into two types of applications: Stateless applications: Requests within a stateless application have no relationship to each other. The 3GPP defined S13 application is an example of a stateless application [S13], --> where only a Diameter command is defined between a client and a server and no state is maintained between two consecutive transactions. Pseudo-session applications: Applications that do not rely on the Session-Id AVP for correlation of application messages related to the same session but use other session-related information in the Diameter requests for this purpose. The 3GPP defined Cx application [Cx] is an example of a pseudo-session application. The Credit-Control application defined in [RFC4006] is an example of a Diameter session-based application. Korhonen, et al. Expires April 23, 2015 [Page 33] Internet-Draft DOIC October 2014 The handling of overload reports must take the type of application into consideration, as discussed in Appendix C.2. C.2. Application Type Overload Implications This section discusses considerations for mitigating overload reported by a Diameter entity. This discussion focuses on the type of application. Appendix C.3 discusses considerations for handling various request types when the target server is known to be in an overloaded state. These discussions assume that the strategy for mitigating the reported overload is to reduce the overall workload sent to the overloaded entity. The concept of applying overload treatment to requests targeted for an overloaded Diameter entity is inherent to this discussion. The method used to reduce offered load is not specified here but could include routing requests to another Diameter entity known to be able to handle them, or it could mean rejecting certain requests. For a Diameter agent, rejecting requests will usually mean generating appropriate Diameter error responses. For a Diameter client, rejecting requests will depend upon the application. For example, it could mean giving an indication to the entity requesting the Diameter service that the network is busy and to try again later. Stateless applications: By definition there is no relationship between individual requests in a stateless application. As a result, when a request is sent or relayed to an overloaded Diameter entity - either a Diameter Server or a Diameter Agent - the sending or relaying entity can choose to apply the overload treatment to any request targeted for the overloaded entity. Pseudo-session applications: For pseudo-session applications, there is an implied ordering of requests. As a result, decisions about which requests towards an overloaded entity to reject could take the command code of the request into consideration. This generally means that transactions later in the sequence of transactions should be given more favorable treatment than messages earlier in the sequence. This is because more work has already been done by the Diameter network for those transactions that occur later in the sequence. Rejecting them could result in increasing the load on the network as the transactions earlier in the sequence might also need to be repeated. Korhonen, et al. Expires April 23, 2015 [Page 34] Internet-Draft DOIC October 2014 Session-based applications: Overload handling for session-based applications must take into consideration the work load associated with setting up and maintaining a session. As such, the entity sending requests towards an overloaded Diameter entity for a session-based application might tend to reject new session requests prior to rejecting intra-session requests. In addition, session ending requests might be given a lower probability of being rejected as rejecting session ending requests could result in session status being out of sync between the Diameter clients and servers. Application designers that would decide to reject mid-session requests will need to consider whether the rejection invalidates the session and any resulting session clean-up procedures. C.3. Request Transaction Classification Independent Request: An independent request is not correlated to any other requests and, as such, the lifetime of the session-id is constrained to an individual transaction. Session-Initiating Request: A session-initiating request is the initial message that establishes a Diameter session. The ACR message defined in [RFC6733] is an example of a session-initiating request. Correlated Session-Initiating Request: There are cases when multiple session-initiated requests must be correlated and managed by the same Diameter server. It is notably the case in the 3GPP PCC architecture [PCC], where multiple apparently independent Diameter application sessions are actually correlated and must be handled by the same Diameter server. Intra-Session Request: An intra session request is a request that uses the same Session- Id than the one used in a previous request. An intra session request generally needs to be delivered to the server that handled the session creating request for the session. The STR message defined in [RFC6733] is an example of an intra-session requests. Pseudo-Session Requests: Korhonen, et al. Expires April 23, 2015 [Page 35] Internet-Draft DOIC October 2014 Pseudo-session requests are independent requests and do not use the same Session-Id but are correlated by other session-related information contained in the request. There exists Diameter applications that define an expected ordering of transactions. This sequencing of independent transactions results in a pseudo session. The AIR, MAR and SAR requests in the 3GPP defined Cx [Cx] application are examples of pseudo-session requests. C.4. Request Type Overload Implications The request classes identified in Appendix C.3 have implications on decisions about which requests should be throttled first. The following list of request treatment regarding throttling is provided as guidelines for application designers when implementing the Diameter overload control mechanism described in this document. The exact behavior regarding throttling is a matter of local policy, unless specifically defined for the application. Independent requests: Independent requests can be given equal treatment when making throttling decisions. Session-initiating requests: Session-initiating requests represent more work than independent or intra-session requests. Moreover, session-initiating requests are typically followed by other session-related requests. As such, as the main objective of the overload control is to reduce the total number of requests sent to the overloaded entity, throttling decisions might favor allowing intra-session requests over session-initiating requests. Individual session-initiating requests can be given equal treatment when making throttling decisions. Correlated session-initiating requests: A Request that results in a new binding, where the binding is used for routing of subsequent session-initiating requests to the same server, represents more work load than other requests. As such, these requests might be throttled more frequently than other request types. Pseudo-session requests: Throttling decisions for pseudo-session requests can take into consideration where individual requests fit into the overall sequence of requests within the pseudo session. Requests that are Korhonen, et al. Expires April 23, 2015 [Page 36] Internet-Draft DOIC October 2014 earlier in the sequence might be throttled more aggressively than requests that occur later in the sequence. Intra-session requests There are two classes of intra-sessions requests. The first class consists of requests that terminate a session. The second one contains the set of requests that are used by the Diameter client and server to maintain the ongoing session state. Session terminating requests should be throttled less aggressively in order to gracefully terminate sessions, allow clean-up of the related resources (e.g. session state) and get rid of the need for other intra-session requests, reducing the session management impact on the overloaded entity. The default handling of other intra-session requests might be to treat them equally when making throttling decisions. There might also be application level considerations whether some request types are favored over others. Authors' Addresses Jouni Korhonen (editor) Broadcom Porkkalankatu 24 Helsinki FIN-00180 Finland Email: jouni.nospam@gmail.com Steve Donovan (editor) Oracle 7460 Warren Parkway Frisco, Texas 75034 United States Email: srdonovan@usdonovans.com Ben Campbell Oracle 7460 Warren Parkway Frisco, Texas 75034 United States Email: ben@nostrum.com Korhonen, et al. Expires April 23, 2015 [Page 37] Internet-Draft DOIC October 2014 Lionel Morand Orange Labs 38/40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France Phone: +33145296257 Email: lionel.morand@orange.com Korhonen, et al. Expires April 23, 2015 [Page 38] --------------040602090603050609000905-- From nobody Tue Oct 21 00:42:33 2014 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 DCA1B1A6FA9 for ; Tue, 21 Oct 2014 00:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YDnOsrWjli3L for ; Tue, 21 Oct 2014 00:42:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 B4DCA1AD0A0 for ; Tue, 21 Oct 2014 00:42:23 -0700 (PDT) Received: from localhost ([::1]:52493 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgU5A-00076x-OG; Tue, 21 Oct 2014 00:42:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com X-Trac-Project: dime Date: Tue, 21 Oct 2014 07:42:16 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/43#comment:2 Message-ID: <072.eeecb0390c7a9273f5816d7aaa8c1dcf@trac.tools.ietf.org> References: <057.97c5ce599fb219f1e97cb7300a394f91@trac.tools.ietf.org> X-Trac-Ticket-ID: 43 In-Reply-To: <057.97c5ce599fb219f1e97cb7300a394f91@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hzNWuOGV4CxkpDI9aEmDpS8H7Fo Cc: dime@ietf.org Subject: Re: [Dime] [dime] #43 (draft-ietf-dime-ovli): Overstated guidance on session-ending requests. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 07:42:32 -0000 #43: Overstated guidance on session-ending requests. Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Changes as suggested by Ben: Independent Request Section: Old: Independent requests can be given equal treatment when making throttling decisions. New: Independent requests can generally be given equal treatment when making throttling decisions, unless otherwise indicated by application requirements or local policy. Session-Initiating Requests: Old: Session-initiating requests represent more work than independent or intra-session requests. Moreover, session-initiating requests are typically followed by other session-related requests. As such, as the main objective of the overload control is to reduce the total number of requests sent to the overloaded entity, throttling decisions might favor allowing intra-session requests over session-initiating requests. Individual session-initiating requests can be given equal treatment when making throttling decisions. New: Session-initiating requests often represent more work than independent or intra-session requests. Moreover, session-initiating requests are typically followed by other session-related requests. Since the main objective of the overload control is to reduce the total number of requests sent to the overloaded entity, throttling decisions might favor allowing intra-session requests over session-initiating requests. In the absence of local policies or application specific requirements to the contrary, Individual session-initiating requests can be given equal treatment when making throttling decisions. Correlated Session-Initiationg Requests and Pseudo-session requests sections: [Existing text is fine as is] Intra-Session Requests: Old: There are two classes of intra-sessions requests. The first class consists of requests that terminate a session. The second one contains the set of requests that are used by the Diameter client and server to maintain the ongoing session state. Session terminating requests should be throttled less aggressively in order to gracefully terminate sessions, allow clean-up of the related resources (e.g. session state) and get rid of the need for other intra-session requests, reducing the session management impact on the overloaded entity. The default handling of other intra-session requests might be to treat them equally when making throttling decisions. There might also be application level considerations whether some request types are favored over others. New: There are two classes of intra-sessions requests. The first class consists of requests that terminate a session. The second class comprises requests that are used by the Diameter client and server to maintain the ongoing session state. Implementors and operators may choose to throttle session-terminating requests less aggressively in order to gracefully terminate sessions, allow clean-up of the related resources (e.g. session state) and avoid the need for additional intra-session requests. Favoring session-termination requests may reduce the session management impact on the overloaded entity. The default handling of other intra-session requests might be to treat them equally when making throttling decisions. There might also be application level considerations whether some request types are favored over others. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Tue Oct 21 01:02:10 2014 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 A1CB11A6FA9 for ; Tue, 21 Oct 2014 00:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 mINWyQMSgdmt for ; Tue, 21 Oct 2014 00:43:17 -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 94E8B1AD0A1 for ; Tue, 21 Oct 2014 00:43:17 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:55092 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgU68-0004pA-5X for dime@ietf.org; Tue, 21 Oct 2014 00:43:17 -0700 Message-ID: <54460E93.408@usdonovans.com> Date: Tue, 21 Oct 2014 09:43:15 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------000609020604070705050506" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7boGmkCuLBtEijCNbUnP82kijoI X-Mailman-Approved-At: Tue, 21 Oct 2014 01:02:09 -0700 Subject: [Dime] Resolution of issue 43 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, 21 Oct 2014 07:43:20 -0000 This is a multi-part message in MIME format. --------------000609020604070705050506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have updated github with Ben's suggested changes to issue 43. I have attached the resulting diff file. Regards, Steve --------------000609020604070705050506 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed. Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed.
Internet-Draft Broadcom Internet-Draft Broadcom
Intended status: Standards Track S. Donovan, Ed. Intended status: Standards Track S. Donovan, Ed.
Expires: April 23, 2015 B. Campbell Expires: April 24, 2015 B. Campbell
Oracle Oracle
L. Morand L. Morand
Orange Labs Orange Labs
October 20, 2014 October 21, 2014
Diameter Overload Indication Conveyance Diameter Overload Indication Conveyance
draft-ietf-dime-ovli-04.txt draft-ietf-dime-ovli-04.txt
Abstract Abstract
This specification documents a Diameter Overload Control (DOC) base This specification documents a Diameter Overload Control (DOC) base
solution and the dissemination of the overload report information. solution and the dissemination of the overload report information.
Requirements Requirements
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2015. This Internet-Draft will expire on April 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 36, line 25 skipping to change at page 36, line 25
The request classes identified in Appendix C.3 have implications on The request classes identified in Appendix C.3 have implications on
decisions about which requests should be throttled first. The decisions about which requests should be throttled first. The
following list of request treatment regarding throttling is provided following list of request treatment regarding throttling is provided
as guidelines for application designers when implementing the as guidelines for application designers when implementing the
Diameter overload control mechanism described in this document. The Diameter overload control mechanism described in this document. The
exact behavior regarding throttling is a matter of local policy, exact behavior regarding throttling is a matter of local policy,
unless specifically defined for the application. unless specifically defined for the application.
Independent requests: Independent requests:
Independent requests can be given equal treatment when making Independent requests can generally be given equal treatment when
throttling decisions. making throttling decisions, unless otherwise indicated by
application requirements or local policy.
Session-initiating requests: Session-initiating requests:
Session-initiating requests represent more work than independent Session-initiating requests often represent more work than
or intra-session requests. Moreover, session-initiating requests independent or intra-session requests. Moreover, session-
are typically followed by other session-related requests. As initiating requests are typically followed by other session-
such, as the main objective of the overload control is to reduce related requests. Since the main objective of the overload
the total number of requests sent to the overloaded entity, control is to reduce the total number of requests sent to the
throttling decisions might favor allowing intra-session requests overloaded entity, throttling decisions might favor allowing
over session-initiating requests. Individual session-initiating intra-session requests over session-initiating requests. In the
requests can be given equal treatment when making throttling absence of local policies or application specific requirements to
decisions. the contrary, Individual session-initiating requests can be given
equal treatment when making throttling decisions.
Correlated session-initiating requests: Correlated session-initiating requests:
A Request that results in a new binding, where the binding is used A Request that results in a new binding, where the binding is used
for routing of subsequent session-initiating requests to the same for routing of subsequent session-initiating requests to the same
server, represents more work load than other requests. As such, server, represents more work load than other requests. As such,
these requests might be throttled more frequently than other these requests might be throttled more frequently than other
request types. request types.
Pseudo-session requests: Pseudo-session requests:
Throttling decisions for pseudo-session requests can take into Throttling decisions for pseudo-session requests can take into
consideration where individual requests fit into the overall consideration where individual requests fit into the overall
sequence of requests within the pseudo session. Requests that are sequence of requests within the pseudo session. Requests that are
earlier in the sequence might be throttled more aggressively than earlier in the sequence might be throttled more aggressively than
requests that occur later in the sequence. requests that occur later in the sequence.
Intra-session requests Intra-session requests:
There are two classes of intra-sessions requests. The first class There are two classes of intra-sessions requests. The first class
consists of requests that terminate a session. The second one consists of requests that terminate a session. The second class
contains the set of requests that are used by the Diameter client comprises requests that are used by the Diameter client and server
and server to maintain the ongoing session state. Session to maintain the ongoing session state. Implementors and operators
terminating requests should be throttled less aggressively in may choose to throttle session-terminating requests less
order to gracefully terminate sessions, allow clean-up of the aggressively in order to gracefully terminate sessions, allow
related resources (e.g. session state) and get rid of the need for clean-up of the related resources (e.g. session state) and avoid
other intra-session requests, reducing the session management the need for additional intra-session requests. Favoring session-
impact on the overloaded entity. The default handling of other termination requests may reduce the session management impact on
intra-session requests might be to treat them equally when making the overloaded entity. The default handling of other intra-
session requests might be to treat them equally when making
throttling decisions. There might also be application level throttling decisions. There might also be application level
considerations whether some request types are favored over others. considerations whether some request types are favored over others.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
Broadcom Broadcom
Porkkalankatu 24 Porkkalankatu 24
Helsinki FIN-00180 Helsinki FIN-00180
Finland Finland
 End of changes. 7 change blocks. 
24 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------000609020604070705050506-- From nobody Tue Oct 21 01:36:28 2014 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 4F0261A1A0A for ; Tue, 21 Oct 2014 01:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yWuCoXO80KTz for ; Tue, 21 Oct 2014 01:36:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 A42C21A006F for ; Tue, 21 Oct 2014 01:27:18 -0700 (PDT) Received: from localhost ([::1]:55224 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgUme-00046U-DF; Tue, 21 Oct 2014 01:27:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Tue, 21 Oct 2014 08:27:12 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/85#comment:2 Message-ID: <081.b0cf784f6031add8c6ce78fe7312e32c@trac.tools.ietf.org> References: <066.8ce734c1c66c770a886774c6bf72f7be@trac.tools.ietf.org> X-Trac-Ticket-ID: 85 In-Reply-To: <066.8ce734c1c66c770a886774c6bf72f7be@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2q8UP-XD4DpvZAAka6-9qJVtT4g Cc: dime@ietf.org Subject: Re: [Dime] [dime] #85 (draft-ietf-dime-ovli): New error response X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 08:36:25 -0000 #85: New error response Comment (by srdonovan@usdonovans.com): Added the following proposed wording to the draft: When a DOIC node rejects a Diameter request due to throttling, the DOIC node needs to select the appropriate error response code. This determination is made based on the probability of the request succeeding if retried on a different path. The DIAMETER_TOO_BUSY response code SHOULD be used when the request is likely to succeed on a different path. For instance, if the request arrived at the reporting node without a Destination-Host AVP then the reporting node might determine that there is an alternative Diameter node that could successfully process the request and that retrying the transaction would not negatively impact the reporting node. The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to indicate that the request should not be retried. This is used when the request is not likely to succeed on a different path and retrying would consume valuable resources during an occurance of overload. For instance, if the request arrived at the reporting node with a Destination-Host AVP populated with its own Diameter identity then the reporting node can assume that retrying the request would result in it coming to the same reporting node. A second example is when an agent that supports the DOIC solution is preforming the role of a reacting node for a non supporting client. Requests that are rejected as a result of DOIC throttling in this scenario would generally be rejected with a DIAMETER_UNABLE_TO_COMPLY response code. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Tue Oct 21 01:53:03 2014 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 1F2111A0191 for ; Tue, 21 Oct 2014 01:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 zewNbmcLqf0e for ; Tue, 21 Oct 2014 01:37:35 -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 525E71A01A8 for ; Tue, 21 Oct 2014 01:28:03 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:55195 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgUnR-000CM5-91; Tue, 21 Oct 2014 01:28:02 -0700 Message-ID: <5446190F.2070804@usdonovans.com> Date: Tue, 21 Oct 2014 10:27:59 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, Ben Campbell References: <5444E8B9.8090002@usdonovans.com> <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> <22114_1413841265_54458171_22114_4224_1_6B7134B31289DC4FAF731D844122B36E8005B4@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <1979_1413867197_5445E6BD_1979_10335_1_s8e3rg7h7yyc2r23mds3uefp.1413867190363@email.android.com> In-Reply-To: <1979_1413867197_5445E6BD_1979_10335_1_s8e3rg7h7yyc2r23mds3uefp.1413867190363@email.android.com> Content-Type: multipart/mixed; boundary="------------080905060407090301080505" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/c33Ef4rLshoFSVTK91tdEqkuB1A X-Mailman-Approved-At: Tue, 21 Oct 2014 01:53:01 -0700 Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for error response wording (issue 85) 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, 21 Oct 2014 08:37:40 -0000 This is a multi-part message in MIME format. --------------080905060407090301080505 Content-Type: multipart/alternative; boundary="------------060807060305010704020507" --------------060807060305010704020507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I have incorporated the following text into the document in the existing, previously empty, section 7. Error Response Codes. I will wait until tomorrow to close issue 85 to allow for discussion of the proposed wording. I have attached the diff as this wording is not in the draft. Regards, Steve --- When a DOIC node rejects a Diameter request due to throttling, the DOIC node needs to select the appropriate error response code. This determination is made based on the probability of the request succeeding if retried on a different path. The DIAMETER_TOO_BUSY response code SHOULD be used when the request is likely to succeed on a different path. For instance, if the request arrived at the reporting node without a Destination-Host AVP then the reporting node might determine that there is an alternative Diameter node that could successfully process the request and that retrying the transaction would not negatively impact the reporting node. The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to indicate that the request should not be retried. This is used when the request is not likely to succeed on a different path and retrying would consume valuable resources during an occurance of overload. For instance, if the request arrived at the reporting node with a Destination-Host AVP populated with its own Diameter identity then the reporting node can assume that retrying the request would result in it coming to the same reporting node. A second example is when an agent that supports the DOIC solution is preforming the role of a reacting node for a non supporting client. Requests that are rejected as a result of DOIC throttling in this scenario would generally be rejected with a DIAMETER_UNABLE_TO_COMPLY response code. On 10/21/14, 6:53 AM, lionel.morand@orange.com wrote: > I agree. > > Lionel > > Envoyé depuis mon Sony Xperia SP d'Orange > > ---- Ben Campbell a écrit ---- > > >> On Oct 20, 2014, at 4:41 PM, wrote: >> >> Hi, >> >> I think that: >> - TOO_BUSY should be restricted to server answer > One of the reasons I think we need to state this by intended result and not by role in the network, is that I expect that an overloaded agent (according to the agent overload draft) might send TOO-BUSY. And a server that acts as an overload authority for a realm might send UNABLE-TO-[COMPLY or DELIVER] to a request that did not contain a Destination-Host AVP. > >> - UNABLE_TO_COMPLY as answer to non-supporting DOIC when no retransmission is required >> - UNABLE_TO_DELIVER to supporting DOIC and to non-supporting DOIC node when retransmission to an alternate peer could be better. >> >> As a second step, we could enhance the answer message (in this draft or in a separate draft if preferred) with an error message (e.g. "Error-Diagnostic") that could provide further information to "new" node that will be then able to adapt their behavior. >> So a supporting DOIC receiving UNABLE_TO_DELIVER/TOO_BUSY with an Error-Diagnostic set to e.g. "severe overload", besides the OLR in the answer, will know that retransmission on the path or a on a different path will likely cause the same error. If no error-diagnostic is sent back or ignored by the non-supporting-DOOIC node, we will go back to the situation prior this draft. >> >> Regards, >> >> Lionel >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell >> Envoyé : lundi 20 octobre 2014 19:10 >> À : Steve Donovan >> Cc : dime@ietf.org >> Objet : Re: [Dime] Proposal for error response wording (issue 85) >> >> I agree that we should generalize these, but I think the direction is not quite right. More inline: >> >>> On Oct 20, 2014, at 5:49 AM, Steve Donovan wrote: >>> >>> We came to the following agreements on error responses: >>> >>> - Servers rejecting a Diameter request due to an overload condition should send a 3002 DIAMETER_TOO_BUSY error response. >>> >>> - Agents rejecting a Diameter request due to an overload condition should send a 5012 DIAMETER_UNABLE_TO_COMPLY. >>> >>> I propose that we generalize this to the following: >>> >>> - Reporting nodes rejecting a Diameter request due to an overload condition SHOULD send a 3002 DIAMETER-TOO-BUSY error response. >>> >>> - Reacting nodes rejecting a Diameter request due to an overload condition SHOULD send a UNABLE-TO-COMPLY. >> I don't think we should state this in terms of reaction and reporting nodes. I think we should generalize to expected behavior. Also, in the case where the downstream node does not support DOIC, I'm not sure it makes sense to say the throttling node is really a reporting node (for that particular relationship.) >> >> My suggestion is we say that, if the throttling node has sufficient information to determine that the request is not likely to succeed if retried on another path, it SHOULD send UNABLE-TO-COMPLY. If it does not have that information, it SHOULD send TOO-BUSY. (we should discuss why this is not a MUST if we have the conditionals in place.) >> >> Then we could go on to say that a reaction node (or agent) would typically fall under the first category, and a reporting node (or server) would typically fall under the second. But there certainly may be cases where a reacting node does not know if other paths could work, and where a reporting node might know that they couldn't. >> >> >>> This would mean that an agent acting as a reporting node (i.e.; server doesn't support DOIC or agent is acting as a server front end) would sent the TOO_BUSY response and an agent acting as a reacting node (i.e.; a client doesn't support DOIC) then it sends a UNABLE_TO_COMPLY response. >>> >>> I propose adding this to a new section 4.2.4. The existing 4.2.4 on agent behavior will be deleted. >>> >>> I will hold off making this change until tomorrow (Tuesday morning). >>> >>> Regards, >>> >>> Steve >>> >>> _______________________________________________ >>> 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. > > --------------060807060305010704020507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have incorporated the following text into the document in the existing, previously empty, section 7. Error Response Codes.

I will wait until tomorrow to close issue 85 to allow for discussion of the proposed wording.

I have attached the diff as this wording is not in the draft.

Regards,

Steve

---

   When a DOIC node rejects a Diameter request due to throttling, the
   DOIC node needs to select the appropriate error response code.  This
   determination is made based on the probability of the request
   succeeding if retried on a different path.

   The DIAMETER_TOO_BUSY response code SHOULD be used when the request
   is likely to succeed on a different path.

      For instance, if the request arrived at the reporting node without
      a Destination-Host AVP then the reporting node might determine
      that there is an alternative Diameter node that could successfully
      process the request and that retrying the transaction would not
      negatively impact the reporting node.

   The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to
   indicate that the request should not be retried.  This is used when
   the request is not likely to succeed on a different path and retrying
   would consume valuable resources during an occurance of overload.

      For instance, if the request arrived at the reporting node with a
      Destination-Host AVP populated with its own Diameter identity then
      the reporting node can assume that retrying the request would
      result in it coming to the same reporting node.

      A second example is when an agent that supports the DOIC solution
      is preforming the role of a reacting node for a non supporting
      client.  Requests that are rejected as a result of DOIC throttling
      in this scenario would generally be rejected with a
      DIAMETER_UNABLE_TO_COMPLY response code.

On 10/21/14, 6:53 AM, lionel.morand@orange.com wrote:
I agree.

Lionel

Envoyé depuis mon Sony Xperia SP d'Orange

---- Ben Campbell a écrit ----



On Oct 20, 2014, at 4:41 PM, <lionel.morand@orange.com> <lionel.morand@orange.com> wrote:

Hi,

I think that:
- TOO_BUSY should be restricted to server answer

One of the reasons I think we need to state this by intended result and not by role in the network, is that I expect that an overloaded agent (according to the agent overload draft) might send TOO-BUSY. And a server that acts as an overload authority for a realm might send UNABLE-TO-[COMPLY or DELIVER] to a request that did not contain a Destination-Host AVP.


- UNABLE_TO_COMPLY as answer to non-supporting DOIC when no retransmission is required
- UNABLE_TO_DELIVER to supporting DOIC and to non-supporting DOIC node when retransmission to an alternate peer could be better.

As a second step, we could enhance the answer message (in this draft or in a separate draft if preferred) with an error message (e.g. "Error-Diagnostic") that could provide further information to "new" node that will be then able to adapt their behavior.
So a supporting DOIC receiving UNABLE_TO_DELIVER/TOO_BUSY with an Error-Diagnostic set to e.g. "severe overload", besides the OLR in the answer, will know that retransmission on the path or a on a different path will likely cause the same error. If no error-diagnostic is sent back or ignored by the non-supporting-DOOIC node, we will go back to the situation prior this draft.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoyé : lundi 20 octobre 2014 19:10
À : Steve Donovan
Cc : dime@ietf.org
Objet : Re: [Dime] Proposal for error response wording (issue 85)

I agree that we should generalize these, but I think the direction is not quite right. More inline:


On Oct 20, 2014, at 5:49 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

We came to the following agreements on error responses:

- Servers rejecting a Diameter request due to an overload condition should send a 3002 DIAMETER_TOO_BUSY error response.

- Agents rejecting a Diameter request due to an overload condition should send a 5012 DIAMETER_UNABLE_TO_COMPLY.

I propose that we generalize this to the following:

- Reporting nodes rejecting a Diameter request due to an overload condition SHOULD send a 3002 DIAMETER-TOO-BUSY error response.

- Reacting nodes rejecting a Diameter request due to an overload condition SHOULD send a UNABLE-TO-COMPLY.

I don't think we should state this in terms of reaction and reporting nodes. I think we should generalize to expected behavior. Also, in the case where the downstream node does not support DOIC, I'm not sure it makes sense to say the throttling node is really a reporting node (for that particular relationship.)

My suggestion is we say that, if the throttling node has sufficient information to determine that the request is not likely to succeed if retried on another path, it SHOULD send UNABLE-TO-COMPLY. If it does not have that information, it SHOULD send TOO-BUSY.   (we should discuss why this is not a MUST if we have the conditionals in place.)

Then we could go on to say that a reaction node (or agent) would typically fall under the first category, and a reporting node (or server) would typically fall under the second. But there certainly may be cases where a reacting node does not know if other paths could work, and where a reporting node might know that they couldn't.



This would mean that an agent acting as a reporting node (i.e.; server doesn't support DOIC or agent is acting as a server front end) would sent the TOO_BUSY response and an agent acting as a reacting node (i.e.; a client doesn't support DOIC) then it sends a UNABLE_TO_COMPLY response.

I propose adding this to a new section 4.2.4.  The existing 4.2.4 on agent behavior will be deleted.

I will hold off making this change until tomorrow (Tuesday morning).

Regards,

Steve

_______________________________________________
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.

--------------060807060305010704020507-- --------------080905060407090301080505 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 2, line 48 skipping to change at page 2, line 48
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 23 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 23
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 24 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 24
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 25 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 25
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 26 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 26
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 27 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 29 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 29
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 29 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 29
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 29 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 30
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Issues left for future specifications . . . . . . . 31 Appendix A. Issues left for future specifications . . . . . . . 32
A.1. Additional traffic abatement algorithms . . . . . . . . . 32 A.1. Additional traffic abatement algorithms . . . . . . . . . 32
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 32 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 32
A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 32 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 33
Appendix B. Deployment Considerations . . . . . . . . . . . . . 32 Appendix B. Deployment Considerations . . . . . . . . . . . . . 33
Appendix C. Considerations for Applications Integrating the DOIC Appendix C. Considerations for Applications Integrating the DOIC
Solution . . . . . . . . . . . . . . . . . . . . . . 33 Solution . . . . . . . . . . . . . . . . . . . . . . 33
C.1. Application Classification . . . . . . . . . . . . . . . 33 C.1. Application Classification . . . . . . . . . . . . . . . 33
C.2. Application Type Overload Implications . . . . . . . . . 34 C.2. Application Type Overload Implications . . . . . . . . . 34
C.3. Request Transaction Classification . . . . . . . . . . . 35 C.3. Request Transaction Classification . . . . . . . . . . . 36
C.4. Request Type Overload Implications . . . . . . . . . . . 36 C.4. Request Type Overload Implications . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This specification defines a base solution for Diameter Overload This specification defines a base solution for Diameter Overload
Control (DOC), refered to as Diameter Overload Indication Conveyance Control (DOC), refered to as Diameter Overload Indication Conveyance
(DOIC). The requirements for the solution are described and (DOIC). The requirements for the solution are described and
discussed in the corresponding design requirements document discussed in the corresponding design requirements document
[RFC7068]. Note that the overload control solution defined in this [RFC7068]. Note that the overload control solution defined in this
specification does not address all the requirements listed in specification does not address all the requirements listed in
[RFC7068]. A number of overload control related features are left [RFC7068]. A number of overload control related features are left
skipping to change at page 27, line 7 skipping to change at page 27, line 7
command within that application that includes the AVP. command within that application that includes the AVP.
The Diameter overload control AVPs SHOULD always be sent with the The Diameter overload control AVPs SHOULD always be sent with the
M-bit cleared when used within existing Diameter applications to M-bit cleared when used within existing Diameter applications to
avoid backward compatibility issues. Otherwise, when reused in newly avoid backward compatibility issues. Otherwise, when reused in newly
defined Diameter applications, the DOC related AVPs SHOULD have the defined Diameter applications, the DOC related AVPs SHOULD have the
M-bit set. M-bit set.
7. Error Response Codes 7. Error Response Codes
Editor's note: This section depends on resolution of issue #27. When a DOIC node rejects a Diameter request due to throttling, the
DOIC node needs to select the appropriate error response code. This
determination is made based on the probability of the request
succeeding if retried on a different path.
The DIAMETER_TOO_BUSY response code SHOULD be used when the request
is likely to succeed on a different path.
For instance, if the request arrived at the reporting node without
a Destination-Host AVP then the reporting node might determine
that there is an alternative Diameter node that could successfully
process the request and that retrying the transaction would not
negatively impact the reporting node.
The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to
indicate that the request should not be retried. This is used when
the request is not likely to succeed on a different path and retrying
would consume valuable resources during an occurance of overload.
For instance, if the request arrived at the reporting node with a
Destination-Host AVP populated with its own Diameter identity then
the reporting node can assume that retrying the request would
result in it coming to the same reporting node.
A second example is when an agent that supports the DOIC solution
is preforming the role of a reacting node for a non supporting
client. Requests that are rejected as a result of DOIC throttling
in this scenario would generally be rejected with a
DIAMETER_UNABLE_TO_COMPLY response code.
8. IANA Considerations 8. IANA Considerations
8.1. AVP codes 8.1. AVP codes
New AVPs defined by this specification are listed in Section 6. All New AVPs defined by this specification are listed in Section 6. All
AVP codes allocated from the 'Authentication, Authorization, and AVP codes allocated from the 'Authentication, Authorization, and
Accounting (AAA) Parameters' AVP Codes registry. Accounting (AAA) Parameters' AVP Codes registry.
8.2. New registries 8.2. New registries
 End of changes. 7 change blocks. 
10 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------080905060407090301080505-- From nobody Tue Oct 21 02:04:57 2014 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 6752D1A00FB for ; Tue, 21 Oct 2014 02:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OvshexMxnwNi for ; Tue, 21 Oct 2014 02:04:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 DC0841A00E5 for ; Tue, 21 Oct 2014 02:04:54 -0700 (PDT) Received: from localhost ([::1]:56658 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgVN3-0002Vd-Mz; Tue, 21 Oct 2014 02:04:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Tue, 21 Oct 2014 09:04:49 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/75#comment:1 Message-ID: <081.571a5c51454a5bf4228f9ebb2b1c1b3b@trac.tools.ietf.org> References: <066.165d20d0969f53f2e18f5a88f737e2d5@trac.tools.ietf.org> X-Trac-Ticket-ID: 75 In-Reply-To: <066.165d20d0969f53f2e18f5a88f737e2d5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-r7zidzrZM9t350qz4gVvJhEXd4 Cc: dime@ietf.org Subject: Re: [Dime] [dime] #75 (draft-ietf-dime-ovli): Proposed changes to Terminology section X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 09:04:56 -0000 #75: Proposed changes to Terminology section Comment (by srdonovan@usdonovans.com): Updated document with the following: Abatement Reaction to receipt of an overload report resulting in a reduction in traffic sent to the reporting node. Abatement actions include diversion and throttling. Abatement Algorithm An algorithm requested by reporting nodes and used by reacting nodes to reduce the amount of traffic sent during an occurrence of overload control. Diversion Abatement of traffic sent to a reporting node by a reacting node in response to receipt of an overload report. The abatement is achieved by diverting traffic from the reporting node to another Diameter node that is able to process the request. Host-Routed Request The set of requests that a reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node. Overload Control State (OCS) State describing an occurrence of overload control maintained by reporting and reacting nodes. Overload Report (OLR) A set of AVPs sent by a reporting node indicating the start or continuation of an occurrence of overload control. Reacting Node A Diameter node that consumes and acts upon a report. Realm-Routed Request The set of requests that a reacting node does not know the host that will service the request. Reporting Node A Diameter node that generates an overload report. (This may or may not be the overloaded node.) Throttling Throttling is the reduction of the number of requests sent to an entity. Throttling can include a client dropping requests, or an agent rejecting requests with appropriate error responses. In extreme cases servers can also throttle requests when requested reductions in traffic does not sufficiently address the overload scenario. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Tue Oct 21 04:17:33 2014 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 C82101A1A88 for ; Tue, 21 Oct 2014 04:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YJmEF7AUXEhb for ; Tue, 21 Oct 2014 04:17:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 BE4801A1A6F for ; Tue, 21 Oct 2014 04:17:28 -0700 (PDT) Received: from localhost ([::1]:35230 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgXRK-0007VF-PP; Tue, 21 Oct 2014 04:17:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com, srdonovan@usdonovans.com X-Trac-Project: dime Date: Tue, 21 Oct 2014 11:17:21 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/58#comment:2 Message-ID: <077.cab7be98f78625b524b3f615da87e121@trac.tools.ietf.org> References: <062.600cb97f5aa115891e91baed3f682f01@trac.tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <062.600cb97f5aa115891e91baed3f682f01@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/s-nKJIVzAY1UJ7_MJbYazE6t9ME Cc: dime@ietf.org Subject: Re: [Dime] [dime] #58 (draft-ietf-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 11:17:31 -0000 #58: Multiple Reporting Nodes for realm-routed-request type reports Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Added the following wording to section 4.2.3 (the reporting node sub section of the overload report handling section): This document assumes that there is a single source for realm-reports for a given realm, or that if multiple nodes can send realm reports, that each such node has full knowledge of the overload state of the entire realm. A reacting node cannot distinguish between receiving realm-reports from a single node, or from multiple nodes. If multiple such nodes exist, they MUST ensure that realm-reports are kept in sync. This includes synchronizing the sequence numbers as well as the reported overload state. The method of doing so is up to the implementation. One way to keep the sequence numbers in sync is to generate the sequence numbers based on system time. -- ----------------------------------+--------------------------- Reporter: ulrich.wiehe@nsn.com | Owner: Ulrich Wiehe Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ----------------------------------+--------------------------- Ticket URL: dime From nobody Tue Oct 21 04:42:42 2014 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 4F5F11A1AEE for ; Tue, 21 Oct 2014 04:42:31 -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 mK7N0-bLlfkI for ; Tue, 21 Oct 2014 04:42:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01BEA1A1ADF for ; Tue, 21 Oct 2014 04:42:24 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 037773B4429; Tue, 21 Oct 2014 13:42:23 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id DD1A3384061; Tue, 21 Oct 2014 13:42:22 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 13:42:22 +0200 From: To: "dime@ietf.org" Thread-Topic: Minutes of the Dime Interim Meeting Thread-Index: Ac/tIRzDIVhmb/hzS+Cmn9BU8KaR3w== Date: Tue, 21 Oct 2014 11:42:21 +0000 Message-ID: <14956_1413891742_5446469E_14956_753_1_6B7134B31289DC4FAF731D844122B36E804DD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.24.114819 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PolIU3Y4guR_YQrWWqKITA9wuKU Subject: [Dime] Minutes of the Dime Interim Meeting 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, 21 Oct 2014 11:42:31 -0000 Hi, Please find below the minutes of the interim that was held in Sophia-Antipo= lis, France, October 16-17, 2014. These minutes capture: - the discussions and conclusions on the remaining open issues on the draft= "Diameter Overload Indication Conveyance" (draft-ietf-dime-ovli-03.txt) - the work plan for the completion of the draft towards a WGLC and IESG rev= iew Regards, Lionel ********************* Attendees: Jouni Khoronen Lionel Morand Ben Campbell Steve Donnovan Martin Dolly Ulrich Wiehe Jean-Jacques trottin maria cruz bartolome benoit claise Susan Shi Agreed agenda: THURSDAY, October 16, 2014 0930-1230 Morning Session I Meeting Room: S905 ROYA * Meeting Preliminaries - Note Well - Note takers - Agenda bashing * Status of the draft since IETF90 - Changes in v04 - Closed Issues - Pending open issues - New open Issues THURSDAY, October 16, 2014 1400-1800 Afternoon Session I Meeting Room: S905 ROYA * Review of the proposed solutions and Discussion on new/pending open issue= s (1/2) FRIDAY, October 17, 2014 0930-1230 Morning Session II Meeting Room: S905 ROYA * Review of the proposed solutions and Discussion on new/pending open issue= s (2/2) * Conclusions FRIDAY, October 17, 2014 1400-1700 Afternoon Session II Meeting Room: S905 ROYA * DOIC next steps and working procedure till WGLC/IETF91 * Wrap-up & Conclusion * End of the meeting * Status of the draft since IETF90 The meeting started by a review of the pending open issues presented by Ste= ve and a prioritization of the points to address during the meeting. It was agreed that any editorial issues can be fixed easily by offline disc= ussions. It was agreed that we need to clarifications any points related to the defi= nition of the report types, DOIC nodes behaviour and maintenance of the ove= rload control states. In this optic, issues #23, #66, #67 and #85 were considered as the points t= o address in priority, as a number of other issues will depend on these one= s. The rest of the two days meeting was dedicated to the resolution of pending= open issues. * Review of the proposed solutions and Discussion on new/pending open issues --Issue #23: DOIC behavior for realm overload Summary: there is some inconsistency regarding the handling of request with= out destination-host AVP. This could be illustrated by the following exampl= e: When reaching a node receiving request without Destination-Host AVP and = performing node selection (e.g. SLF in 3GPP), what happens if there is an a= ctive Overload Control State (OCS) for the selected node? The different pie= ces of text found in the current draft could lead to "redundant" abatements. Output of the discussion: It was agreed that: - the "host" report type applies to: - request containing the Destination-Host AVP - request with no Destination-Host AVP BUT the node processing the request= is responsible of the selection of the node which the request must be addr= essed to. - the "realm" report type applies to request without the destination AND th= e node processing the request does not select the final destination host. =20 Based on these definitions, the text should be reviewed in order to clarify= that a node can either consume a received/generated OLR or forward the OLR= downstream. The idea is that the same request should not be subjected to s= everal abatements. For instance, a request with no destination-host AVP tha= t has survived to a throttling performed by the sending node having an acti= ve OCS of type "realm" should not be throttled by an agent responsible for = the final selection of the node for which there is an active OCS of type "h= ost". Ben has provided some text to clarify this issue. Comment/feedback are requ= ired in order to incorporate this text in the draft. --Issue #85: New error response Summary: Is there a need for a new error response to address requests rejec= ted due to overload abatement? The required behavior in response to the new= code is to not retry the transaction.=20 Output of the discussion: no new error code seems to be required. DIAMETER_TOO_BUSY can be sent back by overloaded server performing throttli= ng to nodes supporting DOIC. DIAMETER_UNABLE_TO_DELIVER can be sent by agent performing throttling to no= des supporting DOIC. DIAMETER_UNABLE_TO_COMPLY can be sent to node not supporting DOIC. In all the cases, the expected behaviour is to limit the number of retransm= issions sent by the reacting node. UNABLE_TO_COMPLY as a permanent error is meant to avoid retransmissions. Bu= t UNABLE_TO_DELIVER does not guarantee that, except if a specific notificat= ion is added in the answer message that will indicate to the reacting node = how to behave. One example could be to add a new AVP in the answer (e.g. "E= rror-Diagnostic") that will be understand by node supporting DOIC. But this= can also be left for future extension/optimization. This must be captured in the draft. Issue #25: Diameter agent behaviour Issue #27: Behavior of agent acting on behalf of Client that does not suppo= rt DOIC Issue #69: Report Type - Realm, with absent Destination-Host the issues above should be solved along issues #23 and #85 will be closed. --Issue #67: OCS for Reporting Nodes - Expiry Time Summary: in the current text describing the OCS information elements, it is= said that Validity Duration and expiry time need to maintained, whereas ac= tually only the expiry time is required to manage the OCS, this information= element derived from the validation time received in the OLR. output of the discussion: It was agreed that OCS information discussed in the draft is given as illus= tration of data required to manage the OCS in reporting/reacting node and t= his does not imply that each of information element needs to be locally sto= red. For instance, some data element can be derived from others. It was also discussed how many times a reporting node needs to send an OLR = with the validation duration set to "0" to indicate that the overload situa= tion is over. It was agreed that the reporting node has to send the OLR wit= h validation duration "0" as long as all the reacting maintaining a corresp= onding active OCS have received the OLR. If there is a way for the reportin= g node to ensure that all the nodes will receive the OLR as soon as sent, t= he OLR can be even sent only once. This needs to be captured in the draft. --Issue #66 Summary: it is unclear what happens when non-supporting agent modifies the = Origin-Host AVP in a Diameter answer that contains a host report from a ser= ver. Output of the discussion: it is not possible to describe the expected behaviour of a proxy, as proxy = manipulation is out of scope of the standardization. SO the consensus is the following one: the current solution assumes that th= ere is no origin-host AVP manipulation. If there is scenario in which a pro= xy does it, it is up to the vendor and/or operator network that such origin= -host manipulation does not impact the DOIC mechanism. --Issue #58: Multiple Reporting Nodes for realm-routed-request type reports Summary: In deployments where more than one node is configured to take the = role of a reporting node for realm-routed-request reports, reacting nodes m= ay receive in different answer messages different realm-routed-request type= OLRs inserted by the different reporting nodes.=20 Output of the discussion: Initially, it was proposed to add a new AVP in OLR of type "realm", e.g. OC= -Source AVP, identifying the node inserting the OLR and enabling the reacti= ng to detect that OLR are coming from different sources. We came up with a = second approach which would not require adding the OC-Source AVP: the propo= sal would be to rely on sequence number generated on time basis. In this c= ase, sequence numbers used by different agent responsible for the realm wil= l be in sync. Each approach will be further described and the group will de= cide the preferred approach and if we have time to get this into the 04 dra= ft (and the subsequent RFC). If not, this will go into an extension draft. --Issue #70: Appendix B - Example Summary: some inconsistency in the description of the behaviour of the agen= t. Output of the discussion: it was agreed that this section was used as check-list to see if nothing is= missing in the OC mechanism. This section will be removed from the final v= ersion of the draft.=20 --Issue #71: Summary: Answer message may not include OC-OLR and still the reporting node= be overloaded, since it is considered as "no change" Output of the discussion: the proposed text is OK --Issue #72: Reacting Node Behaviour when OC-OLR is not received Summary: A clarification is required to consider that an answer message may= not include OC-OLR and still the reporting node be overloaded, since it is= considered as "no change", Output of the discussion: to ensure that all the (potential) reacting nodes have received the OLR, it= is agreed that OLR should be included in every message... unless the respo= nding node has a mean to know that the OLR has been received (e.g. static c= onfiguration). A proper text needs to be provided. --Issue #73: Clarifications on the M-bit Summary: Mbit is mentioned in different places in the 03 draft (sections 4.= 3, 6 and 6.8). It is proposed clarifications to ensure a good consistency b= etween the different sections.=20 Output of the discussion: It is agreed that the draft should just refer to the RFC6733 for everything= regarding the M-bit setting. How and when to set the M-bit is defined in t= he base protocol. --Issue #74: Move section 3.7 Summary: Proposal to move this section to an Appendix. It provides good inf= ormation but having it as part of section 3 decreases the readability of th= e document.=20 Output of the discussion: Actually the section is 3.6 and it is ok to move this section into annex. --Issue #75: Proposed changes to Terminology section Summary: Propose to add a few and change a few definitions in the terminolo= gy section.=20 Output of the discussion: Principle OK but the section should be reviewed. "host-routed" and "realm-r= outed" should be added into this section. --Issue #76: add report type as part of OCS information Summary: Propose to add report type as part of the information included in = the OCS of a reporting node. Output of the discussion: It is agreed that this information may not be part of exact parameter to ma= nage OCS. However, as the section 4.2.1.2 just provides examples of data to= store, it is OK to include Report type as part of possible OCS information. --Issue #77: Section 4.2.3 - Reporting node behavior (overload report handl= ing) Summary: add text regarding inclusion of OC-Validity-Duration AVP and repor= t type in the OLR Output of the discussion: This change is not required as the ABNF of OLR shows that these AVPs are fi= xed AVPs and then always present in the OLR. --Issue #78: Remove section 5.2 Summary: this section is redundant with text provided in other section. Output of the discussion: OK to remove the section --Issue #79: remove the editor's note from section 5.4 summary: Propose to remove the following editor's note from section 5.4 as = the suggested guidance already exists.=20 Output of the discussion: OK --Issue #80: OC-Supported-Features Summary: Propose removing the following from the last paragraph. Also propo= se removing the editor's note:=20 Output of the discussion: Any text related to node behaviour should be removed as this section must o= nly define the AVP. Behaviour of the node should be describe in other secti= ons. --Issue #81: 6.3. OC-OLR AVP Summary: some text was added to decide what to do with multiple OLR of sam= e type. Output of the discussion: This change is not needed as the existing text states "no more than one OLR= of the same type".=20 --Issue #82: 6.4. OC-Sequence-Number AVP Summary: proposed that SQN are unique per OLR and between two DOIC nodes.= =20 Output of the discussion: Principle is OK. It is also clarified that the SQN needs to maintain as lon= g as the OCS is active. --Issue #84: 6.6. OC-Report-Type AVP Summary: proposed to clarify that the default value of the OC-Report-Type A= VP is 0 (i.e. the host report).=20 Output of the discussion: Because it is agreed that the report type will be in every OLR (fixed posit= ion), it is obvious that there is no need to define a default value when ab= sent The discussion was initially raised when it is was proposed to make op= tional the presence of the Report-Type in the OLR, which was not accepted. Conclusion was that OC-Report-Type is mandatory, and fixed position. No def= ault value is applicable Work plan/Timeline: - Submission of version -04 before the submission cut-off (27/10) - Additional meeting during the IETF meeting to finalize the draft - move the document to WGLC as soon as possible after IETF meeting. ___________________________________________________________________________= ______________________________________________ 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 Tue Oct 21 06:02:51 2014 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 045E41A19E3 for ; Tue, 21 Oct 2014 02:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 oOy0-j0SHHPB for ; Tue, 21 Oct 2014 02:35:51 -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 A63AE1A1A0A for ; Tue, 21 Oct 2014 02:33:55 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:55296 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgVpC-0002YQ-2S for dime@ietf.org; Tue, 21 Oct 2014 02:33:55 -0700 Message-ID: <54462880.8020009@usdonovans.com> Date: Tue, 21 Oct 2014 11:33:52 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------070607050000000908020206" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/D2ORrA3ulnP3dvLhLpI1cDARleY X-Mailman-Approved-At: Tue, 21 Oct 2014 06:02:50 -0700 Subject: [Dime] Proposed resolution to issue 75 (terminology) 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, 21 Oct 2014 09:35:55 -0000 This is a multi-part message in MIME format. --------------070607050000000908020206 Content-Type: multipart/alternative; boundary="------------020606080901050601040704" --------------020606080901050601040704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have updated the document with the proposals made in issue 75. I also added definitions for host-routed and realm-routed requests. The updated text is below. I will wait to close the issue until tomorrow to give time for comments. I have attached the diff file. Regards, Steve ---- Abatement Reaction to receipt of an overload report resulting in a reduction in traffic sent to the reporting node. Abatement actions include diversion and throttling. Abatement Algorithm An algorithm requested by reporting nodes and used by reacting nodes to reduce the amount of traffic sent during an occurrence of overload control. Diversion Abatement of traffic sent to a reporting node by a reacting node in response to receipt of an overload report. The abatement is achieved by diverting traffic from the reporting node to another Diameter node that is able to process the request. Host-Routed Request The set of requests that a reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node. Overload Control State (OCS) State describing an occurrence of overload control maintained by reporting and reacting nodes. Overload Report (OLR) A set of AVPs sent by a reporting node indicating the start or continuation of an occurrence of overload control. Reacting Node A Diameter node that consumes and acts upon a report. Realm-Routed Request The set of requests that a reacting node does not know the host that will service the request. Reporting Node A Diameter node that generates an overload report. (This may or may not be the overloaded node.) Throttling Throttling is the reduction of the number of requests sent to an entity. Throttling can include a client dropping requests, or an agent rejecting requests with appropriate error responses. In extreme cases servers can also throttle requests when requested reductions in traffic does not sufficiently address the overload scenario. --------------020606080901050601040704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have updated the document with the proposals made in issue 75.  I also added definitions for host-routed and realm-routed requests.

The updated text is below.

I will wait to close the issue until tomorrow to give time for comments.

I have attached the diff file.

Regards,

Steve

----

   Abatement

      Reaction to receipt of an overload report resulting in a reduction
      in traffic sent to the reporting node.  Abatement actions include
      diversion and throttling.

   Abatement Algorithm

      An algorithm requested by reporting nodes and used by reacting
      nodes to reduce the amount of traffic sent during an occurrence of
      overload control.

   Diversion

      Abatement of traffic sent to a reporting node by a reacting node
      in response to receipt of an overload report.  The abatement is
      achieved by diverting traffic from the reporting node to another
      Diameter node that is able to process the request.

   Host-Routed Request

      The set of requests that a reacting node knows will be served by a
      particular host, either due to the presence of a Destination-Host
      AVP, or by some other local knowledge on the part of the reacting
      node.

   Overload Control State (OCS)

      State describing an occurrence of overload control maintained by
      reporting and reacting nodes.

   Overload Report (OLR)

      A set of AVPs sent by a reporting node indicating the start or
      continuation of an occurrence of overload control.

   Reacting Node

      A Diameter node that consumes and acts upon a report.

   Realm-Routed Request

      The set of requests that a reacting node does not know the host
      that will service the request.

   Reporting Node

      A Diameter node that generates an overload report.  (This may or
      may not be the overloaded node.)

   Throttling

      Throttling is the reduction of the number of requests sent to an
      entity.  Throttling can include a client dropping requests, or an
      agent rejecting requests with appropriate error responses.  In
      extreme cases servers can also throttle requests when requested
      reductions in traffic does not sufficiently address the overload
      scenario.

--------------020606080901050601040704-- --------------070607050000000908020206 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 2, line 16 skipping to change at page 2, line 16
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 6 3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 7
3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7
3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 8 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 9
3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10
3.5. Simplified Example Architecture . . . . . . . . . . . . . 10 3.5. Simplified Example Architecture . . . . . . . . . . . . . 11
4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11
4.1. Capability Announcement . . . . . . . . . . . . . . . . . 11 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 12
4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12
4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12
4.2. Overload Report Processing . . . . . . . . . . . . . . . 13 4.2. Overload Report Processing . . . . . . . . . . . . . . . 13
4.2.1. Overload Control State . . . . . . . . . . . . . . . 13 4.2.1. Overload Control State . . . . . . . . . . . . . . . 13
4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 15 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16
4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17
4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 19 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 19
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 19 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 20 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 21
5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 22 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 22
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 23 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 24
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 24 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 25 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 26 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 26
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 27 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 29 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 30
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 29 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 30 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 30
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Issues left for future specifications . . . . . . . 32 Appendix A. Issues left for future specifications . . . . . . . 32
A.1. Additional traffic abatement algorithms . . . . . . . . . 32 A.1. Additional traffic abatement algorithms . . . . . . . . . 33
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 32 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 33
A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 33 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 33
Appendix B. Deployment Considerations . . . . . . . . . . . . . 33 Appendix B. Deployment Considerations . . . . . . . . . . . . . 33
Appendix C. Considerations for Applications Integrating the DOIC Appendix C. Considerations for Applications Integrating the DOIC
Solution . . . . . . . . . . . . . . . . . . . . . . 33 Solution . . . . . . . . . . . . . . . . . . . . . . 34
C.1. Application Classification . . . . . . . . . . . . . . . 33 C.1. Application Classification . . . . . . . . . . . . . . . 34
C.2. Application Type Overload Implications . . . . . . . . . 34 C.2. Application Type Overload Implications . . . . . . . . . 35
C.3. Request Transaction Classification . . . . . . . . . . . 36 C.3. Request Transaction Classification . . . . . . . . . . . 36
C.4. Request Type Overload Implications . . . . . . . . . . . 36 C.4. Request Type Overload Implications . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This specification defines a base solution for Diameter Overload This specification defines a base solution for Diameter Overload
Control (DOC), refered to as Diameter Overload Indication Conveyance Control (DOC), refered to as Diameter Overload Indication Conveyance
(DOIC). The requirements for the solution are described and (DOIC). The requirements for the solution are described and
discussed in the corresponding design requirements document discussed in the corresponding design requirements document
[RFC7068]. Note that the overload control solution defined in this [RFC7068]. Note that the overload control solution defined in this
specification does not address all the requirements listed in specification does not address all the requirements listed in
skipping to change at page 3, line 43 skipping to change at page 3, line 43
The solution defined in this specification addresses Diameter The solution defined in this specification addresses Diameter
overload control between Diameter nodes that support the DOIC overload control between Diameter nodes that support the DOIC
solution. Furthermore, the solution is designed to apply to existing solution. Furthermore, the solution is designed to apply to existing
and future Diameter applications, requires no changes to the Diameter and future Diameter applications, requires no changes to the Diameter
base protocol [RFC6733] and is deployable in environments where some base protocol [RFC6733] and is deployable in environments where some
Diameter nodes do not implement the Diameter overload control Diameter nodes do not implement the Diameter overload control
solution defined in this specification. solution defined in this specification.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
Abatement Algorithm Abatement
Reaction to receipt of an overload report resulting in a reduction
in traffic sent to the reporting node. Abatement actions include
diversion and throttling.
Abatement Algorithm
An algorithm requested by reporting nodes and used by reacting An algorithm requested by reporting nodes and used by reacting
nodes to reduce the amount of traffic sent during an occurrence of nodes to reduce the amount of traffic sent during an occurrence of
overload control. overload control.
Throttling Diversion
Throttling is the reduction of the number of requests sent to an
entity. Throttling can include a client dropping requests, or an
agent rejecting requests with appropriate error responses.
Clients and agents can also choose to redirect throttled requests
to some other entity or entities capable of handling them.
Editor's note: Propose to add a definition of Abatement to include
both throttling and diversion (redirecting of messages) actions.
Then to modify this definition to include just the rejecting of
requests and adding a definition of diversion.
Reporting Node
A Diameter node that generates an overload report. (This may or Abatement of traffic sent to a reporting node by a reacting node
may not be the overloaded node.) in response to receipt of an overload report. The abatement is
achieved by diverting traffic from the reporting node to another
Diameter node that is able to process the request.
Reacting Node Host-Routed Request
A Diameter node that consumes and acts upon a report. Note that The set of requests that a reacting node knows will be served by a
"act upon" does not necessarily mean the reacting node applies an particular host, either due to the presence of a Destination-Host
abatement algorithm; it might decide to delegate that downstream, AVP, or by some other local knowledge on the part of the reacting
in which case it also becomes a "reporting node". node.
Overload Control State (OCS) Overload Control State (OCS)
State describing an occurrence of overload control maintained by State describing an occurrence of overload control maintained by
reporting and reacting nodes. reporting and reacting nodes.
Overload Report (OLR) Overload Report (OLR)
A set of AVPs sent by a reporting node indicating the start or A set of AVPs sent by a reporting node indicating the start or
continuation of an occurrence of overload control. continuation of an occurrence of overload control.
Reacting Node
A Diameter node that consumes and acts upon a report.
Realm-Routed Request
The set of requests that a reacting node does not know the host
that will service the request.
Reporting Node
A Diameter node that generates an overload report. (This may or
may not be the overloaded node.)
Throttling
Throttling is the reduction of the number of requests sent to an
entity. Throttling can include a client dropping requests, or an
agent rejecting requests with appropriate error responses. In
extreme cases servers can also throttle requests when requested
reductions in traffic does not sufficiently address the overload
scenario.
3. Solution Overview 3. Solution Overview
The Diameter Overload Information Conveyance (DOIC) mechanism allows The Diameter Overload Information Conveyance (DOIC) mechanism allows
Diameter nodes to request other nodes to perform overload abatement Diameter nodes to request other nodes to perform overload abatement
actions, that is, actions to reduce the load offered to the actions, that is, actions to reduce the load offered to the
overloaded node or realm. overloaded node or realm.
A Diameter node that supports DOIC is known as a "DOIC node". Any A Diameter node that supports DOIC is known as a "DOIC node". Any
Diameter node can act as a DOIC node, including clients, servers, and Diameter node can act as a DOIC node, including clients, servers, and
agents. DOIC nodes are further divided into "Reporting Nodes" and agents. DOIC nodes are further divided into "Reporting Nodes" and
 End of changes. 22 change blocks. 
43 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------070607050000000908020206-- From nobody Tue Oct 21 06:03:00 2014 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 A1E0F1A1A90 for ; Tue, 21 Oct 2014 04:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 6ALWPEXyWKLa for ; Tue, 21 Oct 2014 04:22:23 -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 A2DBC1A1A93 for ; Tue, 21 Oct 2014 04:22:23 -0700 (PDT) Received: from [64.31.33.44] (port=56411 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgXW8-0009z3-B8 for dime@ietf.org; Tue, 21 Oct 2014 04:22:21 -0700 Message-ID: <544641EA.4030203@usdonovans.com> Date: Tue, 21 Oct 2014 13:22:18 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------080703070807070005060703" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/WnWjS_DRK_zqj4c4guVWBHwy7uA X-Mailman-Approved-At: Tue, 21 Oct 2014 06:02:50 -0700 Subject: [Dime] Resolution of issue 58 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, 21 Oct 2014 11:22:26 -0000 This is a multi-part message in MIME format. --------------080703070807070005060703 Content-Type: multipart/alternative; boundary="------------030800030604030006080601" --------------030800030604030006080601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have added the following wording to the draft in github: This document assumes that there is a single source for realm-reports for a given realm, or that if multiple nodes can send realm reports, that each such node has full knowledge of the overload state of the entire realm. A reacting node cannot distinguish between receiving realm-reports from a single node, or from multiple nodes. If multiple such nodes exist, they MUST ensure that realm-reports are kept in sync. This includes synchronizing the sequence numbers as well as the reported overload state. The method of doing so is up to the implementation. One way to keep the sequence numbers in sync is to generate the sequence numbers based on system time. I also corrected a previous change in the same that was missing a few words. Thanks to Ulrich for pointing this out. The original text was: When generating sequence numbers for , the new sequence number MUST be greater than any sequence number in an active (unexpired) overload report previously sent by the reporting node. This property MUST hold over a reboot of the reporting node. The new text is: When generating sequence numbers for new overload conditions, the new sequence number MUST be greater than any sequence number in an active (unexpired) overload report previously sent by the reporting node. This property MUST hold over a reboot of the reporting node. I have attached the resulting diff file. Regards, Steve --------------030800030604030006080601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have added the following wording to the draft in github:

   This document assumes that there is a single source for realm-reports
   for a given realm, or that if multiple nodes can send realm reports,
   that each such node has full knowledge of the overload state of the
   entire realm.  A reacting node cannot distinguish between receiving
   realm-reports from a single node, or from multiple nodes.

   If multiple such nodes exist, they MUST ensure that realm-reports are
   kept in sync.  This includes synchronizing the sequence numbers as
   well as the reported overload state.  The method of doing so is up to
   the implementation.  One way to keep the sequence numbers in sync is
   to generate the sequence numbers based on system time.
I also corrected a previous change in the same that was missing a few words.  Thanks to Ulrich for pointing this out.

The original text was:

When generating sequence numbers for , the new
   sequence number MUST be greater than any sequence number in an active
   (unexpired) overload report previously sent by the reporting node.
   This property MUST hold over a reboot of the reporting node.

The new text is: 
When generating sequence numbers for new overload conditions, the new
   sequence number MUST be greater than any sequence number in an active
   (unexpired) overload report previously sent by the reporting node.
   This property MUST hold over a reboot of the reporting node.

I have attached the resulting diff file.

Regards,

Steve
--------------030800030604030006080601-- --------------080703070807070005060703 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 18, line 38 skipping to change at page 18, line 38
indicated by a new feature bit in the OC-Feature-Vector AVP. indicated by a new feature bit in the OC-Feature-Vector AVP.
If OLR is for a new overload condition and there is no unexpired If OLR is for a new overload condition and there is no unexpired
overload report for previous overload conditions at any reacting node overload report for previous overload conditions at any reacting node
then the reporting node MAY set the sequence number to any value. then the reporting node MAY set the sequence number to any value.
The reacting node MAY update the overload report with new reduction The reacting node MAY update the overload report with new reduction
percentages. When doing so, the reacting node MUST increase the percentages. When doing so, the reacting node MUST increase the
sequence number in the new OLR sent. sequence number in the new OLR sent.
When generating sequence numbers for , the new sequence number MUST When generating sequence numbers for new overload conditions, the new
be greater than any sequence number in an active (unexpired) overload sequence number MUST be greater than any sequence number in an active
report previously sent by the reporting node. This property MUST (unexpired) overload report previously sent by the reporting node.
hold over a reboot of the reporting node. This property MUST hold over a reboot of the reporting node.
A reporting node MAY rely on the OC-Validity-Duration AVP values for A reporting node MAY rely on the OC-Validity-Duration AVP values for
the implicit overload control state cleanup on the reacting node. the implicit overload control state cleanup on the reacting node.
However, it is RECOMMENDED that the reporting node always explicitly However, it is RECOMMENDED that the reporting node always explicitly
indicates the end of a overload condition. indicates the end of a overload condition.
The reporting node SHOULD indicate the end of an overload occurrence The reporting node SHOULD indicate the end of an overload occurrence
by sending a new OLR with OC-Validity-Duration set to a value of zero by sending a new OLR with OC-Validity-Duration set to a value of zero
("0"). The reporting node SHOULD insure that all reacting nodes ("0"). The reporting node SHOULD insure that all reacting nodes
receive the updated overload report. receive the updated overload report.
All OLRs sent have an expiration time calculated by adding the All OLRs sent have an expiration time calculated by adding the
validity-duration contained in the OLR to the time the message was validity-duration contained in the OLR to the time the message was
sent. Transit time for the OLR can be safely ignored. The sent. Transit time for the OLR can be safely ignored. The
reporting node can ensure that all reacting nodes have received reporting node can ensure that all reacting nodes have received
the OLR by continuing to send it in answer messages until the the OLR by continuing to send it in answer messages until the
expiration time for all OLRs sent for that overload contition have expiration time for all OLRs sent for that overload contition have
expired. expired.
This document assumes that there is a single source for realm-reports
for a given realm, or that if multiple nodes can send realm reports,
that each such node has full knowledge of the overload state of the
entire realm. A reacting node cannot distinguish between receiving
realm-reports from a single node, or from multiple nodes.
If multiple such nodes exist, they MUST ensure that realm-reports are
kept in sync. This includes synchronizing the sequence numbers as
well as the reported overload state. The method of doing so is up to
the implementation. One way to keep the sequence numbers in sync is
to generate the sequence numbers based on system time.
4.3. Protocol Extensibility 4.3. Protocol Extensibility
The overload control solution can be extended, e.g. with new traffic The overload control solution can be extended, e.g. with new traffic
abatement algorithms, new report types or other new functionality. abatement algorithms, new report types or other new functionality.
When defining a new extension a new feature bit MUST be defined for When defining a new extension a new feature bit MUST be defined for
the OC-Feature-Vector. This feature bit is used to communicate the OC-Feature-Vector. This feature bit is used to communicate
support for the new feature. support for the new feature.
The extention may also define new AVPs for use in DOIC Capability The extention may also define new AVPs for use in DOIC Capability
 End of changes. 2 change blocks. 
4 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------080703070807070005060703-- From nobody Tue Oct 21 07:46:38 2014 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 4088B1A86EE for ; Tue, 21 Oct 2014 07:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YQ2nuNnazmds for ; Tue, 21 Oct 2014 07:46:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 460AB1A6F45 for ; Tue, 21 Oct 2014 07:46:33 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9LEkWwn066101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 09:46:32 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <5446190F.2070804@usdonovans.com> Date: Tue, 21 Oct 2014 09:46:31 -0500 X-Mao-Original-Outgoing-Id: 435595591.814737-dd4b223c4db96d60ac960582baa3022d Content-Transfer-Encoding: quoted-printable Message-Id: <99D5FF0E-2D2B-4DB1-8C9C-19296A8D1822@nostrum.com> References: <5444E8B9.8090002@usdonovans.com> <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> <22114_1413841265_54458171_22114_4224_1_6B7134B31289DC4FAF731D844122B36E8005B4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, <>> <1979_1413867197_5445E6BD_1979_10335_1_s8e3rg7h7yyc2r23mds3uefp.1413867190363@email.android.com> <5446190F.2070804@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/LS4TL1wSJwcjm63DytQH0FnNVBI Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for error response wording (issue 85) 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, 21 Oct 2014 14:46:37 -0000 Did we intend to include anything about Lionel's suggestion on = UNABLE_TO_DELIVER? (I am neutral on that--I just wanted to make sure we = didn't forget to consider it.) I also have one comment inline. Otherwise it looks good to me. > On Oct 21, 2014, at 3:27 AM, Steve Donovan = wrote: >=20 > I have incorporated the following text into the document in the = existing, previously empty, section 7. Error Response Codes. >=20 > I will wait until tomorrow to close issue 85 to allow for discussion = of the proposed wording. >=20 > I have attached the diff as this wording is not in the draft. >=20 > Regards, >=20 > Steve >=20 > --- >=20 > When a DOIC node rejects a Diameter request due to throttling, the > DOIC node needs to select the appropriate error response code. Do we have separate text saying the node MUST send an error? If not, I = suggest changing this to "... MUST respond with an appropriate error = response code." The change from "the" to "an" was intentional. Since we are using SHOULD = below for the actual choice, I assume we intend to leave room for an = implementation to make other choices if it has a good reason.=20 > This > determination is made based on the probability of the request > succeeding if retried on a different path. >=20 > The DIAMETER_TOO_BUSY response code SHOULD be used when the request > is likely to succeed on a different path. >=20 > For instance, if the request arrived at the reporting node = without > a Destination-Host AVP then the reporting node might determine > that there is an alternative Diameter node that could = successfully > process the request and that retrying the transaction would not > negatively impact the reporting node. >=20 > The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to > indicate that the request should not be retried. This is used when > the request is not likely to succeed on a different path and = retrying > would consume valuable resources during an occurance of overload. >=20 > For instance, if the request arrived at the reporting node with = a > Destination-Host AVP populated with its own Diameter identity = then > the reporting node can assume that retrying the request would > result in it coming to the same reporting node. >=20 > A second example is when an agent that supports the DOIC = solution > is preforming the role of a reacting node for a non supporting > client. Requests that are rejected as a result of DOIC = throttling > in this scenario would generally be rejected with a > DIAMETER_UNABLE_TO_COMPLY response code. >=20 >=20 >=20 >=20 > On 10/21/14, 6:53 AM, lionel.morand@orange.com wrote: >> I agree. >>=20 >> Lionel >>=20 >> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>=20 >> ---- Ben Campbell a =E9crit ---- >>=20 >>=20 >>=20 >>> On Oct 20, 2014, at 4:41 PM, = >>> wrote: >>>=20 >>> Hi, >>>=20 >>> I think that: >>> - TOO_BUSY should be restricted to server answer >>>=20 >> One of the reasons I think we need to state this by intended result = and not by role in the network, is that I expect that an overloaded = agent (according to the agent overload draft) might send TOO-BUSY. And a = server that acts as an overload authority for a realm might send = UNABLE-TO-[COMPLY or DELIVER] to a request that did not contain a = Destination-Host AVP. >>=20 >>=20 >>> - UNABLE_TO_COMPLY as answer to non-supporting DOIC when no = retransmission is required >>> - UNABLE_TO_DELIVER to supporting DOIC and to non-supporting DOIC = node when retransmission to an alternate peer could be better. >>>=20 >>> As a second step, we could enhance the answer message (in this draft = or in a separate draft if preferred) with an error message (e.g. = "Error-Diagnostic") that could provide further information to "new" node = that will be then able to adapt their behavior. >>> So a supporting DOIC receiving UNABLE_TO_DELIVER/TOO_BUSY with an = Error-Diagnostic set to e.g. "severe overload", besides the OLR in the = answer, will know that retransmission on the path or a on a different = path will likely cause the same error. If no error-diagnostic is sent = back or ignored by the non-supporting-DOOIC node, we will go back to the = situation prior this draft. >>>=20 >>> Regards, >>>=20 >>> Lionel >>>=20 >>> -----Message d'origine----- >>> De : DiME [ >>> mailto:dime-bounces@ietf.org >>> ] De la part de Ben Campbell >>> Envoy=E9 : lundi 20 octobre 2014 19:10 >>> =C0 : Steve Donovan >>> Cc :=20 >>> dime@ietf.org >>>=20 >>> Objet : Re: [Dime] Proposal for error response wording (issue 85) >>>=20 >>> I agree that we should generalize these, but I think the direction = is not quite right. More inline: >>>=20 >>>=20 >>>> On Oct 20, 2014, at 5:49 AM, Steve Donovan = >>>> wrote: >>>>=20 >>>> We came to the following agreements on error responses: >>>>=20 >>>> - Servers rejecting a Diameter request due to an overload condition = should send a 3002 DIAMETER_TOO_BUSY error response. >>>>=20 >>>> - Agents rejecting a Diameter request due to an overload condition = should send a 5012 DIAMETER_UNABLE_TO_COMPLY. >>>>=20 >>>> I propose that we generalize this to the following: >>>>=20 >>>> - Reporting nodes rejecting a Diameter request due to an overload = condition SHOULD send a 3002 DIAMETER-TOO-BUSY error response. >>>>=20 >>>> - Reacting nodes rejecting a Diameter request due to an overload = condition SHOULD send a UNABLE-TO-COMPLY. >>>>=20 >>> I don't think we should state this in terms of reaction and = reporting nodes. I think we should generalize to expected behavior. = Also, in the case where the downstream node does not support DOIC, I'm = not sure it makes sense to say the throttling node is really a reporting = node (for that particular relationship.) >>>=20 >>> My suggestion is we say that, if the throttling node has sufficient = information to determine that the request is not likely to succeed if = retried on another path, it SHOULD send UNABLE-TO-COMPLY. If it does not = have that information, it SHOULD send TOO-BUSY. (we should discuss why = this is not a MUST if we have the conditionals in place.) >>>=20 >>> Then we could go on to say that a reaction node (or agent) would = typically fall under the first category, and a reporting node (or = server) would typically fall under the second. But there certainly may = be cases where a reacting node does not know if other paths could work, = and where a reporting node might know that they couldn't. >>>=20 >>>=20 >>>=20 >>>> This would mean that an agent acting as a reporting node (i.e.; = server doesn't support DOIC or agent is acting as a server front end) = would sent the TOO_BUSY response and an agent acting as a reacting node = (i.e.; a client doesn't support DOIC) then it sends a UNABLE_TO_COMPLY = response. >>>>=20 >>>> I propose adding this to a new section 4.2.4. The existing 4.2.4 = on agent behavior will be deleted. >>>>=20 >>>> I will hold off making this change until tomorrow (Tuesday = morning). >>>>=20 >>>> Regards, >>>>=20 >>>> Steve >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>>=20 >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>> _______________________________________________ >>> DiME mailing list >>>=20 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>>=20 >>> = __________________________________________________________________________= _______________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>> 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 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> 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 >>=20 >=20 > From nobody Tue Oct 21 14:25:50 2014 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 58A161A8743 for ; Tue, 21 Oct 2014 14:25:46 -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, HTML_MESSAGE=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 bO7omVd35FXk for ; Tue, 21 Oct 2014 14:25:42 -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 1C8DC1A8746 for ; Tue, 21 Oct 2014 14:25:42 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 5A850F686C932 for ; Tue, 21 Oct 2014 21:25:36 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s9LLPdvw018455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Oct 2014 23:25:40 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.50]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 23:25:39 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: Resolution of issue #73 clarifications on M-bit Thread-Index: Ac/tdY66y3ceVxhFS/mKh6XGaLKHmw== Date: Tue, 21 Oct 2014 21:25:39 +0000 Message-ID: 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_E194C2E18676714DACA9C3A2516265D2026E8B37FR712WXCHMBA12z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/LJ26-zxcS56YVmINyF5c5F715d8 Subject: [Dime] Resolution of issue #73 clarifications on M-bit 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, 21 Oct 2014 21:25:46 -0000 --_000_E194C2E18676714DACA9C3A2516265D2026E8B37FR712WXCHMBA12z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all In reference to the Lionel's minutes on issue #73 Clarifications on the M-= bit: Summary: Mbit is mentioned in different places in the 03 draft (sections 4.= 3, 6 and 6.8). It is proposed clarifications to ensure a good consistency b= etween the different sections. Output of the discussion: It is agreed that the draft should just refer to the RFC6733 for everything= regarding the M-bit setting. How and when to set the M-bit is defined in t= he base protocol. I will follow the output of the discussion, taking into account that I thin= k we still need to indicate that for existing applications, the Mbit should= be cleared for backward compatibility. Hereafter the different places where M-bit is mentioned with the proposed c= hanges In 4.3. Protocol Extensibility Existing text: It should be noted that [RFC6733] defined Grouped AVP extension mechanisms apply. This allows, for example, defining a new feature that is mandatory to be understood even when piggybacked on an existing applications. More specifically, the sub-AVPs inside the OC-Supported-Features and OC-OLR AVP MAY have the M-bit set. However, when overload control AVPs are piggybacked on top of an existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED. Proposal: To keep the reference to RFC 6733; the text about existing appl= ications is removed as overlapping with the 6.8 one. It should be noted that [RFC6733] defined Grouped AVP extension mechanisms apply. In 6. Attribute Value Pairs Existing text This section describes the encoding and semantics of the Diameter Overload Indication Attribute Value Pairs (AVPs) defined in this document. When added to existing commands, both OC-Feature-Vector and OC-OLR AVPs SHOULD have the M-bit flag cleared to avoid backward compatibility issues. A new application specification can incorporate the overload control mechanism specified in this document by making it mandatory to implement for the application and referencing this specification normatively. In such a case, the OC-Feature-Vector and OC-OLR AVPs reused in newly defined Diameter applications SHOULD have the M-bit flag set. However, it is the responsibility of the Diameter application designers to define how overload control mechanisms works on that application. Proposal: to remove two paragraphs as overlapping with 6.8 This section describes the encoding and semantics of the Diameter Overload Indication Attribute Value Pairs (AVPs) defined in this document. In 6.8. Attribute Value Pair flag rules Existing text As described in the Diameter base protocol [RFC6733], the M-bit setting for a given AVP is relevant to an application and each command within that application that includes the AVP. The Diameter overload control AVPs SHOULD always be sent with the M-bit cleared when used within existing Diameter applications to avoid backward compatibility issues. Otherwise, when reused in newly defined Diameter applications, the DOC related AVPs SHOULD have the M-bit set. Proposal: To keep the reference to RFC 6733 and the particular case of exis= ting applications As described in the Diameter base protocol [RFC6733], the M-bit setting for a given AVP is relevant to an application and each command within that application that includes the AVP. However, the Diameter overload control AVPs SHOULD always be sent with the M-bit cleared when used within existing Diameter applications to avoid backward compatibility issues. If OK, I will update the proposal for the issue #73 in the Dime Tracker Best regards JJacques --_000_E194C2E18676714DACA9C3A2516265D2026E8B37FR712WXCHMBA12z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all

 

In reference to the Lionel’s minutes on  = issue #73 Clarifications on the M-bit:

Summary: Mbit is men= tioned in different places in the 03 draft (sections 4.3, 6 and 6.8). It is= proposed clarifications to ensure a good consistency between the different= sections.

 

Output of the discus= sion:

It is agreed that th= e draft should just refer to the RFC6733 for everything regarding the M-bit= setting. How and when to set the M-bit is defined in the base protocol.

 

I will follow the output of the discussion, taking i= nto account that I think we still need to indicate that for existing applic= ations, the Mbit should be cleared for backward compatibility.

 

Hereafter the different places where M-bit is mentio= ned with the proposed changes

 

In 4.3.  Protocol Extensibility

 

Existing text:

   It should be noted that [RFC6733] define= d Grouped AVP extension

   mechanisms apply.  This allows, for exam= ple, defining a new feature

   that is mandatory to be understood even when = piggybacked on an

   existing applications.  More specificall= y, the sub-AVPs inside the

   OC-Supported-Features and OC-OLR AVP MAY have= the M-bit set.

   However, when overload control AVPs are piggy= backed on top of an

   existing applications, setting M-bit in sub-A= VPs is NOT RECOMMENDED.

 

Proposal: To keep the reference to RFC 6733;  t= he text about  existing applications is removed as  overlapping w= ith the 6.8 one.

 

   It should be noted that [RFC6733] defined Gro= uped AVP extension

   mechanisms apply.

 

 

In 6.  Attribute Value Pairs

 

Existing text

   This section describes the encoding and seman= tics of the Diameter

   Overload Indication Attribute Value Pairs (AV= Ps) defined in this

   document.

 

   When added to existing commands, both OC-Feat= ure-Vector and OC-OLR

   AVPs SHOULD have the M-bit flag cleared to av= oid backward

   compatibility issues.

 

   A new application specification can incorpora= te the overload control

   mechanism specified in this document by makin= g it mandatory to

   implement for the application and referencing= this specification

   normatively.  In such a case, the OC-Fea= ture-Vector and OC-OLR AVPs

   reused in newly defined Diameter applications= SHOULD have the M-bit

   flag set.  However, it is the responsibi= lity of the Diameter

   application designers to define how overload = control mechanisms works

   on that application.

 

 

Proposal: to remove two paragraphs as overlapping wi= th 6.8

   This section describes the encoding and = semantics of the Diameter

   Overload Indication Attribute Value Pairs (AV= Ps) defined in this

   document.

 

 

In 6.8.  Attribute Value Pair flag rules

 

Existing text

   As described in the Diameter base protocol [R= FC6733], the M-bit

   setting for a given AVP is relevant to an app= lication and each

   command within that application that includes= the AVP.

 

   The Diameter overload control AVPs SHOULD alw= ays be sent with the

   M-bit cleared when used within existing Diame= ter applications to

   avoid backward compatibility issues.  Ot= herwise, when reused in newly

   defined Diameter applications, the DOC relate= d AVPs SHOULD have the

   M-bit set.

 

Proposal: To keep the reference to RFC 6733 and the particular case of existing = applications

 

   As described in the Diameter base protocol [R= FC6733], the M-bit

   setting for a given AVP is relevant to an app= lication and each

   command within that application that includes= the AVP. However, the

   Diameter overload control AVPs SHOULD always = be sent with the

   M-bit cleared when used within existing Diame= ter applications to

   avoid backward compatibility issues.

 

If OK, I will update the proposal for the issue #73 = in the Dime Tracker

 

Best regards

 

JJacques

--_000_E194C2E18676714DACA9C3A2516265D2026E8B37FR712WXCHMBA12z_-- From nobody Tue Oct 21 15:10:19 2014 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 3E2B41A879A for ; Tue, 21 Oct 2014 15:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 iuPqo_emGzPa for ; Tue, 21 Oct 2014 15:10:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4FE341A8764 for ; Tue, 21 Oct 2014 15:10:07 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9LMA5iI018797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 17:10:06 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: Ben Campbell Content-Type: multipart/alternative; boundary="Apple-Mail=_9EFDF2A6-3419-457F-B098-42E53345FCC4" X-Mao-Original-Outgoing-Id: 435622205.185286-c523a46eb674ef8e08bf7466b23266b6 Message-Id: <2A9AB49D-E2FA-4BF9-9399-361464482DA3@nostrum.com> Date: Tue, 21 Oct 2014 17:10:05 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) To: "dime@ietf.org list" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4mj-RJ45ieibX-Km-CiVPm0alng Subject: [Dime] DOIC Requirements Analysis 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, 21 Oct 2014 22:10:16 -0000 --Apple-Mail=_9EFDF2A6-3419-457F-B098-42E53345FCC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Benoit requested that the DOIC draft include a requirements analysis = against the requirements from RFC 7068. I=E2=80=99ve made an attempt = that that, below. I realize not everyone will agree on my analysis, and there is = considerable room for discussion. However, given Benoit=E2=80=99s = request, I think it=E2=80=99s important to get these in as soon as = possible; if not in 04, then soon afterwards (i.e. before WGLC, and = preferably before Honolulu.) I also created a branch called =E2=80=9CReqs-Analysis" in the GitHub = repository that contains these in XML form. Thanks! Ben. ---------------------------------------------- Appendix D. Requirements Analysis This section analyzes the mechanism described in this document against the set of requirements detailed in [RFC7068]. D.1. General REQ 1: The solution MUST provide a communication method for Diameter nodes to exchange load and overload information. *Partially Compliant*. The mechanism uses new AVPs piggybacked on existing Diameter messages to exchange overload information. It does not currently support "load" information. Indication of "Load" information has been left for a future extension. REQ 2: The solution MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support. Diameter clients and agents must be able to use the received load and overload information to support graceful behavior during an overload condition. Graceful behavior under overload conditions is best described by REQ 3. *Compliant*. The DOIC AVPs can be used in any application that allows the extension of AVPs. REQ 3: The solution MUST limit the impact of overload on the overall useful throughput of a Diameter server, even when the incoming load on the network is far in excess of its capacity. The overall useful throughput under load is the ultimate measure of the value of a solution. *Compliant*. DOIC provides information that nodes can use to reduce the impact of overload. REQ 4: Diameter allows requests to be sent from either side of a connection, and either side of a connection may have need to provide its overload status. The solution MUST allow each side of a connection to independently inform the other of its overload status. *Compliant*. DOIC AVPs can be included regardless of transaction "direction" REQ 5: Diameter allows nodes to determine their peers via dynamic discovery or manual configuration. The solution MUST work consistently without regard to how peers are determined. *Compliant*. DOIC contains no assumptions about how peers are discovered. [Note: This may require further study] REQ 6: The solution designers SHOULD seek to minimize the amount of new configuration required in order to work. For example, it is better to allow peers to advertise or negotiate support for the solution, rather than to require that this knowledge to be configured at each node. *Partially Compliant*. Most DOIC parameters are advertised using the DOIC capability announcement mechanism. However, there are some situations where configuration is required. For example, a DOIC node detect the fact that a peer may not support DOIC when nodes on the other side of the non- supporting node do support DOIC without configuration. D.2. Performance REQ 7: The solution and any associated default algorithm(s) MUST ensure that the system remains stable. At some point after an overload condition has ended, the solution MUST enable capacity to stabilize and become equal to what it would be in the absence of an overload condition. Note that this also requires that the solution MUST allow nodes to shed load without introducing non-converging oscillations during or after an overload condition. *Compliant*. The specification offers guidance that implementations should apply hysteresis when recovering from overload, and avoid sudden ramp ups in offered load when recovering. REQ 8: Supporting nodes MUST be able to distinguish current overload information from stale information. *Partially Compliant*. DOIC overload reports are "soft state", that is they expire after an indicated period. DOIC nodes may also send reports that end existing overload conditions. DOIC requires reporting nodes to ensure that all relevant reacting nodes receive overload reports. However, since DOIC does not allow reports to send OLRs in watchdog messages, if an overload condition results in zero offered load, the reporting node cannot update the condition until the expiration of the original OLR. REQ 9: The solution MUST function across fully loaded as well as quiescent transport connections. This is partially derived from the requirement for stability in REQ 7. *Not Compliant*. DOIC does not allow OLRs to be sent over quiescent transport connections. This is due to the fact that OLRs cannot be sent outside of the application to which they apply. REQ 10: Consumers of overload information MUST be able to determine when the overload condition improves or ends. *Partially Compliant*. (See response to previous two requirements.) REQ 11: The solution MUST be able to operate in networks of different sizes. *Compliant*. DOIC makes no assumptions about the size of the network. DOIC can operate purely between clients and servers, or across agents. REQ 12: When a single network node fails, goes into overload, or suffers from reduced processing capacity, the solution MUST make it possible to limit the impact of the affected node on other nodes in the network. This helps to prevent a small- scale failure from becoming a widespread outage. *Partially Compliant*. DOIC allows overload reports for an entire realm, where abated traffic will not be redirected towards another server. But in situations where nodes choose to divert traffic to other nodes, DOIC offers no way of knowing whether the new recipients can handle the traffic if they have not already indicated overload. This may be mitigated with the use of a future "load" extension, or with the use of proprietary dynamic load-balancing mechanisms. REQ 13: The solution MUST NOT introduce substantial additional work for a node in an overloaded state. For example, a requirement for an overloaded node to send overload information every time it received a new request would introduce substantial work. *Not Compliant*. DOIC does in fact encourage an overloaded node to send an OLR in every response. The working group that other mechanisms to ensure that every relevant node receives an OLR would create even more work. [Note: This needs discussion.] REQ 14: Some scenarios that result in overload involve a rapid increase of traffic with little time between normal levels and levels that induce overload. The solution SHOULD provide for rapid feedback when traffic levels increase. *Compliant*. The piggyback mechanism allows OLRs to be sent at the same rate as application traffic. REQ 15: The solution MUST NOT interfere with the congestion control mechanisms of underlying transport protocols. For example, a solution that opened additional TCP connections when the network is congested would reduce the effectiveness of the underlying congestion control mechanisms. *Compliant*. DOIC does not require or recommend changes in the handling of transport protocols or connections. D.3. Heterogeneous Support for Solution REQ 16: The solution is likely to be deployed incrementally. The solution MUST support a mixed environment where some, but not all, nodes implement it. *Partially Compliant*. DOIC works with most mixed-deployment scenarios. However, it cannot work across a non-supporting proxy that modifies Origin-Host AVPs in answer messages. DOIC will have limited impact in networks where the nodes that perform server selections do not support the mechanism. REQ 17: In a mixed environment with nodes that support the solution and nodes that do not, the solution MUST NOT result in materially less useful throughput during overload as would have resulted if the solution were not present. It SHOULD result in less severe overload in this environment. *Compliant*. In most mixed-support deployment, DOIC will offer at least some value, and will not make things worse. REQ 18: In a mixed environment of nodes that support the solution and nodes that do not, the solution MUST NOT preclude elements that support overload control from treating elements that do not support overload control in an equitable fashion relative to those that do. Users and operators of nodes that do not support the solution MUST NOT unfairly benefit from the solution. The solution specification SHOULD provide guidance to implementors for dealing with elements not supporting overload control. *Compliant*. DOIC provides mechanisms to abate load from non- supporting sources. Furthermore, it recommends that reporting nodes will still need to be able to apply whatever protections they would ordinarily apply if DOIC were not in use. REQ 19: It MUST be possible to use the solution between nodes in different realms and in different administrative domains. *Partially Compliant*. DOIC allows sending OLRs across administrative domains, and potentially to nodes in other realms. However, an OLR cannot indicate overload for realms other than the one in the Origin-Realm AVP of the containing answer. REQ 20: Any explicit overload indication MUST be clearly distinguishable from other errors reported via Diameter. *Compliant*. DOIC sends explicit overload indication in overload reports. It does not depend on error result codes. [Note: I don't think the resuse of too-busy and unable-to- comply for throttled requests impacts this requirement. Do others agree?] REQ 21: In cases where a network node fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure, it may not be able to provide explicit indications of the nature of the failure or its levels of overload. The solution MUST result in at least as much useful throughput as would have resulted if the solution were not in place. *Compliant*. DOIC overload reports have the primary effect of suppressing message retries in overload conditions. DOIC recommends that messages never be silently dropped if at all possible. D.4. Granular Control REQ 22: The solution MUST provide a way for a node to throttle the amount of traffic it receives from a peer node. This throttling SHOULD be graded so that it can be applied gradually as offered load increases. Overload is not a binary state; there may be degrees of overload. *Compliant*. The "loss" algorithm expresses a percentage reduction. REQ 23: The solution MUST provide sufficient information to enable a load-balancing node to divert messages that are rejected or otherwise throttled by an overloaded upstream node to other upstream nodes that are the most likely to have sufficient capacity to process them. *Not Compliant*. DOIC provides no built in mechanism to determine the best place to divert messages that would otherwise be throttled. This can be accomplished with a future "load" extension, or with proprietary load balancing mechanisms. REQ 24: The solution MUST provide a mechanism for indicating load levels, even when not in an overload condition, to assist nodes in making decisions to prevent overload conditions from occurring. *Not Compliant*. "Load" information has been left for a future extension. D.5. Priority and Policy REQ 25: The base specification for the solution SHOULD offer general guidance on which message types might be desirable to send or process over others during times of overload, based on application-specific considerations. For example, it may be more beneficial to process messages for existing sessions ahead of new sessions. Some networks may have a requirement to give priority to requests associated with emergency sessions. Any normative or otherwise detailed definition of the relative priorities of message types during an overload condition will be the responsibility of the application specification. *Compliant*. The specification offers guidance on how requests might be prioritized for different types of applications. REQ 26: The solution MUST NOT prevent a node from prioritizing requests based on any local policy, so that certain requests are given preferential treatment, given additional retransmission, not throttled, or processed ahead of others. *Compliant*. Nothing in the specification prevents application-specific, implementation-specific, or local policies. D.6. Security REQ 27: The solution MUST NOT provide new vulnerabilities to malicious attack or increase the severity of any existing vulnerabilities. This includes vulnerabilities to DoS and DDoS attacks as well as replay and man-in-the-middle attacks. Note that the Diameter base specification [RFC6733] lacks end-to-end security and this must be considered (see the Security Considerations in [RFC7068]). Note that this requirement was expressed at a high level so as to not preclude any particular solution. Is is expected that the solution will address this in more detail. *Unknown*. [Needs further analysis.] REQ 28: The solution MUST NOT depend on being deployed in environments where all Diameter nodes are completely trusted. It SHOULD operate as effectively as possible in environments where other nodes are malicious; this includes preventing malicious nodes from obtaining more than a fair share of service. Note that this does not imply any responsibility on the solution to detect, or take countermeasures against, malicious nodes. *Partially Compliant*. Since all Diameter security is currently at the transport layer, nodes must trust immediate peers to enforce trust policies. However, there are situations where a DOIC node cannot determine if an immediate peer supports DOIC. The authors recommend an expert security review. REQ 29: It MUST be possible for a supporting node to make authorization decisions about what information will be sent to peer nodes based on the identity of those nodes. This allows a domain administrator who considers the load of their nodes to be sensitive information to restrict access to that information. Of course, in such cases, there is no expectation that the solution itself will help prevent overload from that peer node. *Partially Compliant*. (See response to previous requirement.) REQ 30: The solution MUST NOT interfere with any Diameter-compliant method that a node may use to protect itself from overload from non-supporting nodes or from denial-of-service attacks. *Compliant*. The specification recommends that any such protection mechanism needed without DOIC should continue to be employed with DOIC. D.7. Flexibility and Extensibility REQ 31: There are multiple situations where a Diameter node may be overloaded for some purposes but not others. For example, this can happen to an agent or server that supports multiple applications, or when a server depends on multiple external resources, some of which may become overloaded while others are fully available. The solution MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without unreasonably forcing available capacity to go unused. The solution MUST support specification of overload information with granularities of at least "Diameter node", "realm", and "Diameter application" and MUST allow extensibility for others to be added in the future. *Partially Compliant*. All DOIC overload reports are scoped to the specific application and realm. Inside that scope, overload can be reported at the specific server or whole realm scope. As currently specified, DOIC cannot indicate local overload for an agent. At the time of this writing, the DIME working group has plans to work on an agent-overload extension. DOIC allows new "scopes" through the use of extended report types. REQ 32: The solution MUST provide a method for extending the information communicated and the algorithms used for overload control. *Compliant*. DOIC allows new report types and abatement algorithms to be created. These may be indicated using the OC-Supported-Features AVP. REQ 33: The solution MUST provide a default algorithm that is mandatory to implement. *Compliant*. The "loss" algorithm is mandatory to implement. REQ 34: The solution SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the solution. *Partially Compliant*. DOIC information can traverse non- supporting agents, as long as those agents do not modify certain AVPs. (e.g., Origin-Host) --Apple-Mail=_9EFDF2A6-3419-457F-B098-42E53345FCC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 
Hi,
Benoit requested that the DOIC draft include a =
requirements analysis against the requirements from RFC 7068. I=E2=80=99ve=
 made an attempt that that, below.
I realize not everyone =
will agree on my analysis, and there is considerable room for =
discussion. However, given Benoit=E2=80=99s request, I think it=E2=80=99s =
important to get these in as soon as possible; if not in 04, then soon =
afterwards (i.e. before WGLC, and preferably before Honolulu.)
I =
also created a branch called =E2=80=9CReqs-Analysis" in the GitHub =
repository that contains  these in XML form.
Thanks!
Ben.
----------------------------------------------
Appendix D.  Requirements Analysis

   This section analyzes the mechanism described in this document
   against the set of requirements detailed in [RFC7068].

D.1.  General

   REQ 1:  The solution MUST provide a communication method for Diameter
           nodes to exchange load and overload information.

           *Partially Compliant*. The mechanism uses new AVPs
           piggybacked on existing Diameter messages to exchange
           overload information.  It does not currently support "load"
           information.  Indication of "Load" information has been left
           for a future extension.



   REQ 2:  The solution MUST allow Diameter nodes to support overload
           control regardless of which Diameter applications they
           support.  Diameter clients and agents must be able to use the
           received load and overload information to support graceful
           behavior during an overload condition.  Graceful behavior
           under overload conditions is best described by REQ 3.

           *Compliant*. The DOIC AVPs can be used in any application
           that allows the extension of AVPs.



   REQ 3:  The solution MUST limit the impact of overload on the overall
           useful throughput of a Diameter server, even when the
           incoming load on the network is far in excess of its
           capacity.  The overall useful throughput under load is the
           ultimate measure of the value of a solution.

           *Compliant*. DOIC provides information that nodes can use to
           reduce the impact of overload.



   REQ 4:  Diameter allows requests to be sent from either side of a
           connection, and either side of a connection may have need to
           provide its overload status.  The solution MUST allow each
           side of a connection to independently inform the other of its
           overload status.

           *Compliant*. DOIC AVPs can be included regardless of
           transaction "direction"



   REQ 5:  Diameter allows nodes to determine their peers via dynamic
           discovery or manual configuration.  The solution MUST work
           consistently without regard to how peers are determined.

           *Compliant*. DOIC contains no assumptions about how peers are
           discovered.  [Note: This may require further study]



   REQ 6:  The solution designers SHOULD seek to minimize the amount of
           new configuration required in order to work.  For example, it
           is better to allow peers to advertise or negotiate support
           for the solution, rather than to require that this knowledge
           to be configured at each node.

           *Partially Compliant*. Most DOIC parameters are advertised
           using the DOIC capability announcement mechanism.  However,
           there are some situations where configuration is required.
           For example, a DOIC node detect the fact that a peer may not
           support DOIC when nodes on the other side of the non-
           supporting node do support DOIC without configuration.



D.2.  Performance

   REQ 7:  The solution and any associated default algorithm(s) MUST
           ensure that the system remains stable.  At some point after
           an overload condition has ended, the solution MUST enable
           capacity to stabilize and become equal to what it would be in
           the absence of an overload condition.  Note that this also
           requires that the solution MUST allow nodes to shed load
           without introducing non-converging oscillations during or
           after an overload condition.

           *Compliant*. The specification offers guidance that
           implementations should apply hysteresis when recovering from
           overload, and avoid sudden ramp ups in offered load when
           recovering.



   REQ 8:  Supporting nodes MUST be able to distinguish current overload
           information from stale information.

           *Partially Compliant*. DOIC overload reports are "soft
           state", that is they expire after an indicated period.  DOIC
           nodes may also send reports that end existing overload
           conditions.  DOIC requires reporting nodes to ensure that all
           relevant reacting nodes receive overload reports.

           However, since DOIC does not allow reports to send OLRs in
           watchdog messages, if an overload condition results in zero
           offered load, the reporting node cannot update the condition
           until the expiration of the original OLR.



   REQ 9:  The solution MUST function across fully loaded as well as
           quiescent transport connections.  This is partially derived
           from the requirement for stability in REQ 7.

           *Not Compliant*. DOIC does not allow OLRs to be sent over
           quiescent transport connections.  This is due to the fact
           that OLRs cannot be sent outside of the application to which
           they apply.



   REQ 10: Consumers of overload information MUST be able to determine
           when the overload condition improves or ends.

           *Partially Compliant*. (See response to previous two
           requirements.)



   REQ 11: The solution MUST be able to operate in networks of different
           sizes.

           *Compliant*. DOIC makes no assumptions about the size of the
           network.  DOIC can operate purely between clients and
           servers, or across agents.



   REQ 12: When a single network node fails, goes into overload, or
           suffers from reduced processing capacity, the solution MUST
           make it possible to limit the impact of the affected node on
           other nodes in the network.  This helps to prevent a small-
           scale failure from becoming a widespread outage.

           *Partially Compliant*. DOIC allows overload reports for an
           entire realm, where abated traffic will not be redirected
           towards another server.  But in situations where nodes choose
           to divert traffic to other nodes, DOIC offers no way of
           knowing whether the new recipients can handle the traffic if
           they have not already indicated overload.  This may be
           mitigated with the use of a future "load" extension, or with
           the use of proprietary dynamic load-balancing mechanisms.



   REQ 13: The solution MUST NOT introduce substantial additional work
           for a node in an overloaded state.  For example, a
           requirement for an overloaded node to send overload
           information every time it received a new request would
           introduce substantial work.

           *Not Compliant*. DOIC does in fact encourage an overloaded
           node to send an OLR in every response.  The working group
           that other mechanisms to ensure that every relevant node
           receives an OLR would create even more work.  [Note: This
           needs discussion.]



   REQ 14: Some scenarios that result in overload involve a rapid
           increase of traffic with little time between normal levels
           and levels that induce overload.  The solution SHOULD provide
           for rapid feedback when traffic levels increase.

           *Compliant*. The piggyback mechanism allows OLRs to be sent
           at the same rate as application traffic.



   REQ 15: The solution MUST NOT interfere with the congestion control
           mechanisms of underlying transport protocols.  For example, a
           solution that opened additional TCP connections when the
           network is congested would reduce the effectiveness of the
           underlying congestion control mechanisms.

           *Compliant*. DOIC does not require or recommend changes in
           the handling of transport protocols or connections.



D.3.  Heterogeneous Support for Solution

   REQ 16: The solution is likely to be deployed incrementally.  The
           solution MUST support a mixed environment where some, but not
           all, nodes implement it.

           *Partially Compliant*. DOIC works with most mixed-deployment
           scenarios.  However, it cannot work across a non-supporting
           proxy that modifies Origin-Host AVPs in answer messages.
           DOIC will have limited impact in networks where the nodes
           that perform server selections do not support the mechanism.



   REQ 17: In a mixed environment with nodes that support the solution
           and nodes that do not, the solution MUST NOT result in
           materially less useful throughput during overload as would
           have resulted if the solution were not present.  It SHOULD
           result in less severe overload in this environment.

           *Compliant*. In most mixed-support deployment, DOIC will
           offer at least some value, and will not make things worse.



   REQ 18: In a mixed environment of nodes that support the solution and
           nodes that do not, the solution MUST NOT preclude elements
           that support overload control from treating elements that do
           not support overload control in an equitable fashion relative
           to those that do.  Users and operators of nodes that do not
           support the solution MUST NOT unfairly benefit from the
           solution.  The solution specification SHOULD provide guidance
           to implementors for dealing with elements not supporting
           overload control.

           *Compliant*. DOIC provides mechanisms to abate load from non-
           supporting sources.  Furthermore, it recommends that
           reporting nodes will still need to be able to apply whatever
           protections they would ordinarily apply if DOIC were not in
           use.



   REQ 19: It MUST be possible to use the solution between nodes in
           different realms and in different administrative domains.

           *Partially Compliant*. DOIC allows sending OLRs across
           administrative domains, and potentially to nodes in other
           realms.  However, an OLR cannot indicate overload for realms
           other than the one in the Origin-Realm AVP of the containing
           answer.



   REQ 20: Any explicit overload indication MUST be clearly
           distinguishable from other errors reported via Diameter.

           *Compliant*. DOIC sends explicit overload indication in
           overload reports.  It does not depend on error result codes.
           [Note: I don't think the resuse of too-busy and unable-to-
           comply for throttled requests impacts this requirement.  Do
           others agree?]



   REQ 21: In cases where a network node fails, is so overloaded that it
           cannot process messages, or cannot communicate due to a
           network failure, it may not be able to provide explicit
           indications of the nature of the failure or its levels of
           overload.  The solution MUST result in at least as much
           useful throughput as would have resulted if the solution were
           not in place.

           *Compliant*. DOIC overload reports have the primary effect of
           suppressing message retries in overload conditions.  DOIC
           recommends that messages never be silently dropped if at all
           possible.



D.4.  Granular Control

   REQ 22: The solution MUST provide a way for a node to throttle the
           amount of traffic it receives from a peer node.  This
           throttling SHOULD be graded so that it can be applied
           gradually as offered load increases.  Overload is not a
           binary state; there may be degrees of overload.

           *Compliant*. The "loss" algorithm expresses a percentage
           reduction.



   REQ 23: The solution MUST provide sufficient information to enable a
           load-balancing node to divert messages that are rejected or
           otherwise throttled by an overloaded upstream node to other
           upstream nodes that are the most likely to have sufficient
           capacity to process them.

           *Not Compliant*. DOIC provides no built in mechanism to
           determine the best place to divert messages that would
           otherwise be throttled.  This can be accomplished with a
           future "load" extension, or with proprietary load balancing
           mechanisms.



   REQ 24: The solution MUST provide a mechanism for indicating load
           levels, even when not in an overload condition, to assist
           nodes in making decisions to prevent overload conditions from
           occurring.

           *Not Compliant*. "Load" information has been left for a
           future extension.



D.5.  Priority and Policy

   REQ 25: The base specification for the solution SHOULD offer general
           guidance on which message types might be desirable to send or
           process over others during times of overload, based on
           application-specific considerations.  For example, it may be
           more beneficial to process messages for existing sessions
           ahead of new sessions.  Some networks may have a requirement
           to give priority to requests associated with emergency
           sessions.  Any normative or otherwise detailed definition of
           the relative priorities of message types during an overload
           condition will be the responsibility of the application
           specification.

           *Compliant*. The specification offers guidance on how
           requests might be prioritized for different types of
           applications.



   REQ 26: The solution MUST NOT prevent a node from prioritizing
           requests based on any local policy, so that certain requests
           are given preferential treatment, given additional
           retransmission, not throttled, or processed ahead of others.

           *Compliant*. Nothing in the specification prevents
           application-specific, implementation-specific, or local
           policies.



D.6.  Security

   REQ 27: The solution MUST NOT provide new vulnerabilities to
           malicious attack or increase the severity of any existing
           vulnerabilities.  This includes vulnerabilities to DoS and
           DDoS attacks as well as replay and man-in-the-middle attacks.
           Note that the Diameter base specification [RFC6733] lacks
           end-to-end security and this must be considered (see the
           Security Considerations in [RFC7068]).  Note that this
           requirement was expressed at a high level so as to not
           preclude any particular solution.  Is is expected that the
           solution will address this in more detail.

           *Unknown*. [Needs further analysis.]



   REQ 28: The solution MUST NOT depend on being deployed in
           environments where all Diameter nodes are completely trusted.
           It SHOULD operate as effectively as possible in environments
           where other nodes are malicious; this includes preventing
           malicious nodes from obtaining more than a fair share of
           service.  Note that this does not imply any responsibility on
           the solution to detect, or take countermeasures against,
           malicious nodes.

           *Partially Compliant*. Since all Diameter security is
           currently at the transport layer, nodes must trust immediate
           peers to enforce trust policies.  However, there are
           situations where a DOIC node cannot determine if an immediate
           peer supports DOIC.  The authors recommend an expert security
           review.



   REQ 29: It MUST be possible for a supporting node to make
           authorization decisions about what information will be sent
           to peer nodes based on the identity of those nodes.  This
           allows a domain administrator who considers the load of their
           nodes to be sensitive information to restrict access to that
           information.  Of course, in such cases, there is no
           expectation that the solution itself will help prevent
           overload from that peer node.

           *Partially Compliant*. (See response to previous
           requirement.)



   REQ 30: The solution MUST NOT interfere with any Diameter-compliant
           method that a node may use to protect itself from overload
           from non-supporting nodes or from denial-of-service attacks.

           *Compliant*. The specification recommends that any such
           protection mechanism needed without DOIC should continue to
           be employed with DOIC.



D.7.  Flexibility and Extensibility

   REQ 31: There are multiple situations where a Diameter node may be
           overloaded for some purposes but not others.  For example,
           this can happen to an agent or server that supports multiple
           applications, or when a server depends on multiple external
           resources, some of which may become overloaded while others
           are fully available.  The solution MUST allow Diameter nodes
           to indicate overload with sufficient granularity to allow
           clients to take action based on the overloaded resources
           without unreasonably forcing available capacity to go unused.
           The solution MUST support specification of overload
           information with granularities of at least "Diameter node",
           "realm", and "Diameter application" and MUST allow
           extensibility for others to be added in the future.

           *Partially Compliant*. All DOIC overload reports are scoped
           to the specific application and realm.  Inside that scope,
           overload can be reported at the specific server or whole
           realm scope.  As currently specified, DOIC cannot indicate
           local overload for an agent.  At the time of this writing,
           the DIME working group has plans to work on an agent-overload
           extension.

           DOIC allows new "scopes" through the use of extended report
           types.



   REQ 32: The solution MUST provide a method for extending the
           information communicated and the algorithms used for overload
           control.

           *Compliant*. DOIC allows new report types and abatement
           algorithms to be created.  These may be indicated using the
           OC-Supported-Features AVP.



   REQ 33: The solution MUST provide a default algorithm that is
           mandatory to implement.

           *Compliant*. The "loss" algorithm is mandatory to implement.



   REQ 34: The solution SHOULD provide a method for exchanging overload
           and load information between elements that are connected by
           intermediaries that do not support the solution.

           *Partially Compliant*. DOIC information can traverse non-
           supporting agents, as long as those agents do not modify
           certain AVPs. (e.g., Origin-Host)

= --Apple-Mail=_9EFDF2A6-3419-457F-B098-42E53345FCC4-- From nobody Tue Oct 21 21:52:41 2014 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 21FDA1A8A8D for ; Tue, 21 Oct 2014 21:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GzhrvdcCg-F6 for ; Tue, 21 Oct 2014 21:52:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 9A0711A8A9F for ; Tue, 21 Oct 2014 21:52:38 -0700 (PDT) Received: from localhost ([::1]:37069 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgnuR-00044B-RG; Tue, 21 Oct 2014 21:52:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Wed, 22 Oct 2014 04:52:31 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/75#comment:2 Message-ID: <081.07718243e39f1dc00699b63e4033781d@trac.tools.ietf.org> References: <066.165d20d0969f53f2e18f5a88f737e2d5@trac.tools.ietf.org> X-Trac-Ticket-ID: 75 In-Reply-To: <066.165d20d0969f53f2e18f5a88f737e2d5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9znM6C4nHuzLHxuyfV1GNO7il94 Cc: dime@ietf.org Subject: Re: [Dime] [dime] #75 (draft-ietf-dime-ovli): Proposed changes to Terminology section X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 04:52:40 -0000 #75: Proposed changes to Terminology section Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Tue Oct 21 21:55:14 2014 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 EE23D1A8AAA for ; Tue, 21 Oct 2014 21:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cdy9uIxymRly for ; Tue, 21 Oct 2014 21:55:10 -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 E238D1A8A9D for ; Tue, 21 Oct 2014 21:55:10 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:53907 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xgnwr-0001zA-PU; Tue, 21 Oct 2014 21:55:06 -0700 Message-ID: <544738A5.7090608@usdonovans.com> Date: Wed, 22 Oct 2014 06:55:01 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell References: <5444E8B9.8090002@usdonovans.com> <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> <22114_1413841265_54458171_22114_4224_1_6B7134B31289DC4FAF731D844122B36E8005B4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, <>> <1979_1413867197_5445E6BD_1979_10335_1_s8e3rg7h7yyc2r23mds3uefp.1413867190363@email.android.com> <5446190F.2070804@usdonovans.com> <99D5FF0E-2D2B-4DB1-8C9C-19296A8D1822@nostrum.com> In-Reply-To: <99D5FF0E-2D2B-4DB1-8C9C-19296A8D1822@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2a6-2BCo3ksTkI00xtU9HxQEicw Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for error response wording (issue 85) 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, 22 Oct 2014 04:55:13 -0000 It wasn't clear to me when that would be used. We can certainly update the text if someone has an agreeable suggestion for what that text should be. In the mean time, I'm going to close the issue and leave this question to be resolved during review of the updates. Regards, Steve On 10/21/14, 4:46 PM, Ben Campbell wrote: > Did we intend to include anything about Lionel's suggestion on UNABLE_TO_DELIVER? (I am neutral on that--I just wanted to make sure we didn't forget to consider it.) > > I also have one comment inline. Otherwise it looks good to me. > > >> On Oct 21, 2014, at 3:27 AM, Steve Donovan wrote: >> >> I have incorporated the following text into the document in the existing, previously empty, section 7. Error Response Codes. >> >> I will wait until tomorrow to close issue 85 to allow for discussion of the proposed wording. >> >> I have attached the diff as this wording is not in the draft. >> >> Regards, >> >> Steve >> >> --- >> >> When a DOIC node rejects a Diameter request due to throttling, the >> DOIC node needs to select the appropriate error response code. > Do we have separate text saying the node MUST send an error? If not, I suggest changing this to "... MUST respond with an appropriate error response code." > > The change from "the" to "an" was intentional. Since we are using SHOULD below for the actual choice, I assume we intend to leave room for an implementation to make other choices if it has a good reason. > > >> This >> determination is made based on the probability of the request >> succeeding if retried on a different path. >> >> The DIAMETER_TOO_BUSY response code SHOULD be used when the request >> is likely to succeed on a different path. >> >> For instance, if the request arrived at the reporting node without >> a Destination-Host AVP then the reporting node might determine >> that there is an alternative Diameter node that could successfully >> process the request and that retrying the transaction would not >> negatively impact the reporting node. >> >> The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to >> indicate that the request should not be retried. This is used when >> the request is not likely to succeed on a different path and retrying >> would consume valuable resources during an occurance of overload. >> >> For instance, if the request arrived at the reporting node with a >> Destination-Host AVP populated with its own Diameter identity then >> the reporting node can assume that retrying the request would >> result in it coming to the same reporting node. >> >> A second example is when an agent that supports the DOIC solution >> is preforming the role of a reacting node for a non supporting >> client. Requests that are rejected as a result of DOIC throttling >> in this scenario would generally be rejected with a >> DIAMETER_UNABLE_TO_COMPLY response code. >> >> >> >> >> On 10/21/14, 6:53 AM, lionel.morand@orange.com wrote: >>> I agree. >>> >>> Lionel >>> >>> Envoyé depuis mon Sony Xperia SP d'Orange >>> >>> ---- Ben Campbell a écrit ---- >>> >>> >>> >>>> On Oct 20, 2014, at 4:41 PM, >>>> wrote: >>>> >>>> Hi, >>>> >>>> I think that: >>>> - TOO_BUSY should be restricted to server answer >>>> >>> One of the reasons I think we need to state this by intended result and not by role in the network, is that I expect that an overloaded agent (according to the agent overload draft) might send TOO-BUSY. And a server that acts as an overload authority for a realm might send UNABLE-TO-[COMPLY or DELIVER] to a request that did not contain a Destination-Host AVP. >>> >>> >>>> - UNABLE_TO_COMPLY as answer to non-supporting DOIC when no retransmission is required >>>> - UNABLE_TO_DELIVER to supporting DOIC and to non-supporting DOIC node when retransmission to an alternate peer could be better. >>>> >>>> As a second step, we could enhance the answer message (in this draft or in a separate draft if preferred) with an error message (e.g. "Error-Diagnostic") that could provide further information to "new" node that will be then able to adapt their behavior. >>>> So a supporting DOIC receiving UNABLE_TO_DELIVER/TOO_BUSY with an Error-Diagnostic set to e.g. "severe overload", besides the OLR in the answer, will know that retransmission on the path or a on a different path will likely cause the same error. If no error-diagnostic is sent back or ignored by the non-supporting-DOOIC node, we will go back to the situation prior this draft. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> -----Message d'origine----- >>>> De : DiME [ >>>> mailto:dime-bounces@ietf.org >>>> ] De la part de Ben Campbell >>>> Envoyé : lundi 20 octobre 2014 19:10 >>>> À : Steve Donovan >>>> Cc : >>>> dime@ietf.org >>>> >>>> Objet : Re: [Dime] Proposal for error response wording (issue 85) >>>> >>>> I agree that we should generalize these, but I think the direction is not quite right. More inline: >>>> >>>> >>>>> On Oct 20, 2014, at 5:49 AM, Steve Donovan >>>>> wrote: >>>>> >>>>> We came to the following agreements on error responses: >>>>> >>>>> - Servers rejecting a Diameter request due to an overload condition should send a 3002 DIAMETER_TOO_BUSY error response. >>>>> >>>>> - Agents rejecting a Diameter request due to an overload condition should send a 5012 DIAMETER_UNABLE_TO_COMPLY. >>>>> >>>>> I propose that we generalize this to the following: >>>>> >>>>> - Reporting nodes rejecting a Diameter request due to an overload condition SHOULD send a 3002 DIAMETER-TOO-BUSY error response. >>>>> >>>>> - Reacting nodes rejecting a Diameter request due to an overload condition SHOULD send a UNABLE-TO-COMPLY. >>>>> >>>> I don't think we should state this in terms of reaction and reporting nodes. I think we should generalize to expected behavior. Also, in the case where the downstream node does not support DOIC, I'm not sure it makes sense to say the throttling node is really a reporting node (for that particular relationship.) >>>> >>>> My suggestion is we say that, if the throttling node has sufficient information to determine that the request is not likely to succeed if retried on another path, it SHOULD send UNABLE-TO-COMPLY. If it does not have that information, it SHOULD send TOO-BUSY. (we should discuss why this is not a MUST if we have the conditionals in place.) >>>> >>>> Then we could go on to say that a reaction node (or agent) would typically fall under the first category, and a reporting node (or server) would typically fall under the second. But there certainly may be cases where a reacting node does not know if other paths could work, and where a reporting node might know that they couldn't. >>>> >>>> >>>> >>>>> This would mean that an agent acting as a reporting node (i.e.; server doesn't support DOIC or agent is acting as a server front end) would sent the TOO_BUSY response and an agent acting as a reacting node (i.e.; a client doesn't support DOIC) then it sends a UNABLE_TO_COMPLY response. >>>>> >>>>> I propose adding this to a new section 4.2.4. The existing 4.2.4 on agent behavior will be deleted. >>>>> >>>>> I will hold off making this change until tomorrow (Tuesday morning). >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> >>>>> _______________________________________________ >>>>> 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. >>> >>> >>> >> > From nobody Tue Oct 21 21:55:39 2014 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 5777D1A8A9D for ; Tue, 21 Oct 2014 21:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sjZonSUYZRDx for ; Tue, 21 Oct 2014 21:55:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 E947C1A8AAA for ; Tue, 21 Oct 2014 21:55:28 -0700 (PDT) Received: from localhost ([::1]:37169 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgnxG-0004cr-90; Tue, 21 Oct 2014 21:55:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Wed, 22 Oct 2014 04:55:26 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/85#comment:3 Message-ID: <081.f3d1608b49ea6f5903c812a8c1a06f56@trac.tools.ietf.org> References: <066.8ce734c1c66c770a886774c6bf72f7be@trac.tools.ietf.org> X-Trac-Ticket-ID: 85 In-Reply-To: <066.8ce734c1c66c770a886774c6bf72f7be@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/st3TmW7MgdqutRsEF1zW4-E0kqM Cc: dime@ietf.org Subject: Re: [Dime] [dime] #85 (draft-ietf-dime-ovli): New error response X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 04:55:34 -0000 #85: New error response Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Tue Oct 21 22:14:26 2014 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 0F8801A8AB2 for ; Tue, 21 Oct 2014 22:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aEdHgzupfC5D for ; Tue, 21 Oct 2014 22:14:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 CE1FF1A8AB1 for ; Tue, 21 Oct 2014 22:14:10 -0700 (PDT) Received: from localhost ([::1]:38165 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgoFL-00063b-BZ; Tue, 21 Oct 2014 22:14:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com X-Trac-Project: dime Date: Wed, 22 Oct 2014 05:14:07 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/69#comment:1 Message-ID: <090.16cf468c04859cecb89fbc6961f85480@trac.tools.ietf.org> References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tu2FPd0s9i5wSzhRwpmWaJfwL9I Cc: dime@ietf.org Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 05:14:21 -0000 #69: Report Type - Realm, with absent Destination-Host Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Added the following wording resulting from discussions at the interim meeting: When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes. Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the OLR applies. That is, the same candidate set of messages SHOULD NOT be throttled multiple times. However, when the reporting node sends and OLR downstream, it MAY still be responsible to apply other abatement methods, such as diversion, or request throttling requests for other reasons. For example, an agent or server might have a configured rate limit for each client, and throttle requests that exceed that limit, even if such requests had already been candidates for throttling by downstream nodes. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Tue Oct 21 22:16:43 2014 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 035BC1A8AB3 for ; Tue, 21 Oct 2014 22:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 I0rOVWCMvu91 for ; Tue, 21 Oct 2014 22:16:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 699CD1A8AB1 for ; Tue, 21 Oct 2014 22:16:39 -0700 (PDT) Received: from localhost ([::1]:38291 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgoHl-00054x-3P; Tue, 21 Oct 2014 22:16:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Wed, 22 Oct 2014 05:16:37 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/27#comment:4 Message-ID: <081.03b27dad4ba0732051ec323e4d6c389e@trac.tools.ietf.org> References: <066.f61ef866d851ac5c96a3d95ef727dae3@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <066.f61ef866d851ac5c96a3d95ef727dae3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pQgK71fnBch3JJLylwLMgMFu6SU Cc: dime@ietf.org Subject: Re: [Dime] [dime] #27 (draft-ietf-dime-ovli): Behavior of agent acting on behalf of Client that does not support DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 05:16:41 -0000 #27: Behavior of agent acting on behalf of Client that does not support DOIC Comment (by srdonovan@usdonovans.com): Depended on error response section being finished. With that finished this ticket can be closed. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-docdt-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: reopened Priority: critical | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Submitted WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Tue Oct 21 22:16:55 2014 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 72F3E1A8AB9 for ; Tue, 21 Oct 2014 22:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jN9qlPFAOC_E for ; Tue, 21 Oct 2014 22:16:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 66B801A8AB6 for ; Tue, 21 Oct 2014 22:16:47 -0700 (PDT) Received: from localhost ([::1]:38310 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgoHt-0005rL-Kh; Tue, 21 Oct 2014 22:16:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com X-Trac-Project: dime Date: Wed, 22 Oct 2014 05:16:45 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/27#comment:5 Message-ID: <081.8af1c12bc878722afd48078c2178fffc@trac.tools.ietf.org> References: <066.f61ef866d851ac5c96a3d95ef727dae3@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <066.f61ef866d851ac5c96a3d95ef727dae3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com, jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ELh0N8Ty34aM6q_8DWgoMW9g1uA Cc: dime@ietf.org Subject: Re: [Dime] [dime] #27 (draft-ietf-dime-ovli): Behavior of agent acting on behalf of Client that does not support DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 05:16:52 -0000 #27: Behavior of agent acting on behalf of Client that does not support DOIC Changes (by srdonovan@usdonovans.com): * status: reopened => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-docdt-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: critical | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Tue Oct 21 22:17:47 2014 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 564981A8AB3 for ; Tue, 21 Oct 2014 22:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 czbrCgq4rbYG for ; Tue, 21 Oct 2014 22:17:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 3BA9F1A8AB1 for ; Tue, 21 Oct 2014 22:17:45 -0700 (PDT) Received: from localhost ([::1]:38875 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgoIo-0002lf-Ec; Tue, 21 Oct 2014 22:17:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com X-Trac-Project: dime Date: Wed, 22 Oct 2014 05:17:42 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/25#comment:2 Message-ID: <081.fe541f93c4bf71c55309d3075abd8925@trac.tools.ietf.org> References: <066.bb0f61f3d4c3a1f543554c66031a4edd@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <066.bb0f61f3d4c3a1f543554c66031a4edd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gO2mGqupJL7kBYIs8wiiL7wYenE Cc: dime@ietf.org Subject: Re: [Dime] [dime] #25 (draft-ietf-dime-ovli): Section 3.1.5 Diameter Agent Behavior X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 05:17:46 -0000 #25: Section 3.1.5 Diameter Agent Behavior Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: All dependencies have been addressed and as such the ticket can be closed. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Tue Oct 21 22:18:31 2014 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 9233E1A8ABB for ; Tue, 21 Oct 2014 22:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CACrmauW0P8d for ; Tue, 21 Oct 2014 22:18:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 3FA201A8AB3 for ; Tue, 21 Oct 2014 22:18:26 -0700 (PDT) Received: from localhost ([::1]:38981 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgoJT-0006MU-Ue; Tue, 21 Oct 2014 22:18:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com X-Trac-Project: dime Date: Wed, 22 Oct 2014 05:18:23 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/23#comment:2 Message-ID: <081.ca21e61f33b5706b7bb69fae3b643b05@trac.tools.ietf.org> References: <066.bc8b33b812f849d70cc96ca6c7f6d77d@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <066.bc8b33b812f849d70cc96ca6c7f6d77d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QG6nr9BPv6tAfz-spZLoRN-wFwY Cc: dime@ietf.org Subject: Re: [Dime] [dime] #23 (draft-ietf-dime-ovli): DOIC behavior for realm overload X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 05:18:27 -0000 #23: DOIC behavior for realm overload Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: With the resolution to issue 69 this ticket can be closed. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: draft-ietf-dime-ovli | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Tue Oct 21 22:19:26 2014 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 B75DE1A8AC0 for ; Tue, 21 Oct 2014 22:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0cQE5dIKvmtJ for ; Tue, 21 Oct 2014 22:19:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 30C951A8AB1 for ; Tue, 21 Oct 2014 22:19:23 -0700 (PDT) Received: from localhost ([::1]:39058 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XgoKQ-0002zC-17; Tue, 21 Oct 2014 22:19:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com, srdonovan@usdonovans.com X-Trac-Project: dime Date: Wed, 22 Oct 2014 05:19:22 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/58#comment:3 Message-ID: <077.88bb2c0e97c1ae5bb5f0db6ccc815e1e@trac.tools.ietf.org> References: <062.600cb97f5aa115891e91baed3f682f01@trac.tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <062.600cb97f5aa115891e91baed3f682f01@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/okmaFs6ovEakk5DLFto3GzWDSI8 Cc: dime@ietf.org Subject: Re: [Dime] [dime] #58 (draft-ietf-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 05:19:25 -0000 #58: Multiple Reporting Nodes for realm-routed-request type reports Changes (by srdonovan@usdonovans.com): * status: closed => reopened * resolution: fixed => Comment: Consensus has not been reached on the proposed changes so the ticket is being reopened. -- ----------------------------------+--------------------------- Reporter: ulrich.wiehe@nsn.com | Owner: Ulrich Wiehe Type: defect | Status: reopened Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | ----------------------------------+--------------------------- Ticket URL: dime From nobody Tue Oct 21 22:31:23 2014 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 6815D1A8AC6 for ; Tue, 21 Oct 2014 22:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.179 X-Spam-Level: ** X-Spam-Status: No, score=2.179 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_24=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 d74znVMtkkpl for ; Tue, 21 Oct 2014 22:31:10 -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 BAA9C1A8ABE for ; Tue, 21 Oct 2014 22:31:10 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:54074 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgoVi-0002be-N2 for dime@ietf.org; Tue, 21 Oct 2014 22:31:08 -0700 Message-ID: <54474116.5040700@usdonovans.com> Date: Wed, 22 Oct 2014 07:31:02 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------030209050001040106090500" 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ekxoAzBc5WzbOFJRh74K9QC74C8 Subject: [Dime] Status of -04 draft 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, 22 Oct 2014 05:31:22 -0000 This is a multi-part message in MIME format. --------------030209050001040106090500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, We briefly had all of the issues closed. Then I re-opened issue 58 as we have not yet reached consensus on that issue. So, we have one issue open. If we can come to consensus on wording for that issue very quickly then it will be part of -04. If we can't come to consensus by Friday or Saturday then it will need to be left for an extension. I have attached the latest snapshot of the .txt file. The following steps remain: - End-to-end review of draft to remove redundant statements. - Update based on comments received from Benoit, Jouni and Maria Cruz. - General editorial updates. - Continued review by the working group. As a reminder, the document submission deadline is Monday. Anyone who wants review comments reflected in -04 should post them on the list no later than Saturday. Regards, Steve --------------030209050001040106090500 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-dime-ovli-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-dime-ovli-04.txt" Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed. Internet-Draft Broadcom Intended status: Standards Track S. Donovan, Ed. Expires: April 24, 2015 B. Campbell Oracle L. Morand Orange Labs October 21, 2014 Diameter Overload Indication Conveyance draft-ietf-dime-ovli-04.txt Abstract This specification documents a Diameter Overload Control (DOC) base solution and the dissemination of the overload report information. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 24, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Korhonen, et al. Expires April 24, 2015 [Page 1] Internet-Draft DOIC October 2014 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 7 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 7 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 9 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10 3.5. Simplified Example Architecture . . . . . . . . . . . . . 11 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 12 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 4.2. Overload Report Processing . . . . . . . . . . . . . . . 13 4.2.1. Overload Control State . . . . . . . . . . . . . . . 13 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 19 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 21 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 22 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 23 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 23 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 24 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 24 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 25 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 29 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 30 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30 Korhonen, et al. Expires April 24, 2015 [Page 2] Internet-Draft DOIC October 2014 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 31 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 32 Appendix A. Issues left for future specifications . . . . . . . 33 A.1. Additional traffic abatement algorithms . . . . . . . . . 33 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 33 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 33 Appendix B. Deployment Considerations . . . . . . . . . . . . . 33 Appendix C. Considerations for Applications Integrating the DOIC Solution . . . . . . . . . . . . . . . . . . . . . . 34 C.1. Application Classification . . . . . . . . . . . . . . . 34 C.2. Application Type Overload Implications . . . . . . . . . 35 C.3. Request Transaction Classification . . . . . . . . . . . 36 C.4. Request Type Overload Implications . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction This specification defines a base solution for Diameter Overload Control (DOC), refered to as Diameter Overload Indication Conveyance (DOIC). The requirements for the solution are described and discussed in the corresponding design requirements document [RFC7068]. Note that the overload control solution defined in this specification does not address all the requirements listed in [RFC7068]. A number of overload control related features are left for the future specifications. The solution defined in this specification addresses Diameter overload control between Diameter nodes that support the DOIC solution. Furthermore, the solution is designed to apply to existing and future Diameter applications, requires no changes to the Diameter base protocol [RFC6733] and is deployable in environments where some Diameter nodes do not implement the Diameter overload control solution defined in this specification. 2. Terminology and Abbreviations Abatement Reaction to receipt of an overload report resulting in a reduction in traffic sent to the reporting node. Abatement actions include diversion and throttling. Abatement Algorithm Korhonen, et al. Expires April 24, 2015 [Page 3] Internet-Draft DOIC October 2014 An algorithm requested by reporting nodes and used by reacting nodes to reduce the amount of traffic sent during an occurrence of overload control. Diversion Abatement of traffic sent to a reporting node by a reacting node in response to receipt of an overload report. The abatement is achieved by diverting traffic from the reporting node to another Diameter node that is able to process the request. Host-Routed Request The set of requests that a reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node. Overload Control State (OCS) State describing an occurrence of overload control maintained by reporting and reacting nodes. Overload Report (OLR) A set of AVPs sent by a reporting node indicating the start or continuation of an occurrence of overload control. Reacting Node A Diameter node that consumes and acts upon a report. Realm-Routed Request The set of requests that a reacting node does not know the host that will service the request. Reporting Node A Diameter node that generates an overload report. (This may or may not be the overloaded node.) Throttling Throttling is the reduction of the number of requests sent to an entity. Throttling can include a client dropping requests, or an agent rejecting requests with appropriate error responses. In extreme cases servers can also throttle requests when requested Korhonen, et al. Expires April 24, 2015 [Page 4] Internet-Draft DOIC October 2014 reductions in traffic does not sufficiently address the overload scenario. 3. Solution Overview The Diameter Overload Information Conveyance (DOIC) mechanism allows Diameter nodes to request other nodes to perform overload abatement actions, that is, actions to reduce the load offered to the overloaded node or realm. A Diameter node that supports DOIC is known as a "DOIC node". Any Diameter node can act as a DOIC node, including clients, servers, and agents. DOIC nodes are further divided into "Reporting Nodes" and "Reacting Nodes." A reporting node requests overload abatement by sending an Overload Report (OLR) to one or more reacting nodes. A reacting node consumes OLRs, and performs whatever actions are needed to fulfill the abatement requests included in the OLRs. A Reporting node may report overload on its own behalf, or on behalf of other (typically upstream) nodes. Likewise, a reacting node may perform overload abatement on its own behalf, or on behalf of other (typically downstream) nodes. A node's role as a DOIC node is independent of its Diameter role. For example, Diameter relay and proxy agents may act as DOIC nodes, even though they are not endpoints in the Diameter sense. Since Diameter enables bi-directional applications, where Diameter servers can send requests towards Diameter clients, a given Diameter node can simultaneously act as a reporting node and a reacting node. Likewise, a relay or proxy agent may act as a reacting node from the perspective of upstream nodes, and a reporting node from the perspective of downstream nodes. DOIC nodes do not generate new messages to carry DOIC related information. Rather, they "piggyback" DOIC information over existing Diameter messages by inserting new AVPs into existing Diameter requests and responses. Nodes indicate support for DOIC, and any needed DOIC parameters by inserting an OC_Supported_Features AVP (Section 6.2) into existing requests and responses. Reporting nodes send OLRs by inserting OC-OLR AVPs (Section 6.3). A given OLR applies to the Diameter realm and application of the Diameter message that carries it. If a reporting node supports more than one realm and/or application, it reports independently for each combination of realm and application. Similarly, OC-Feature-Vector Korhonen, et al. Expires April 24, 2015 [Page 5] Internet-Draft DOIC October 2014 AVPs apply to the realm and application of the enclosing message. This implies that a node may support DOIC for one application and/or realm, but not another, and may indicate different DOIC parameters for each application and realm for which it supports DOIC. Reacting nodes perform overload abatement according to an agreed-upon abatement algorithm. An abatement algorithm defines the meaning of the parameters of an OLR, and the procedures required for overload abatement. This document specifies a single must-support algorithm, namely the "loss" algorithm Section 5). Future specifications may introduce new algorithms. Overload conditions may vary in scope. For example, a single Diameter node may be overloaded, in which case reacting nodes may reasonably attempt to send throttled requests to other destinations or via other agents. On the other hand, an entire Diameter realm may be overloaded, in which case such attempts would do harm. DOIC OLRs have a concept of "report type" (Section 6.6), where the type defines such behaviors. Report types are extensible. This document defines report types for overload of a specific server, and for overload of an entire realm. A report of type host is sent to indicate the overload of a specific server for the application-id indicated in the transaction. When receiving an OLR of type host, a reacting node applies overload abatement to what is referred to in this document as host-routed requests. This is the set of requests that the reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node. The reacting node applies overload abatement on those host-routed requests which the reacting node knows will be served by the server that matches the Origin-Host AVP of the received message that contained the received OLR of type host. A report type of realm is sent to indicate the overload of all servers in a realm for the application-id. When receiving an OLR of type realm, a reacting node applies overload abatement to what is referred to in this document as realm-routed requests. This is the set of requests that are not host-routed as defined in the previous paragraph. While a reporting node sends OLRs to "adjacent" reacting nodes, nodes that are "adjacent" for DOIC purposes may not be adjacent from a Diameter, or transport, perspective. For example, one or more Diameter agents that do not support DOIC may exist between a given pair of reporting and reacting nodes, as long as those agents pass unknown AVPs through unmolested. The report types described in this document can safely pass through non-supporting agents. This may not Korhonen, et al. Expires April 24, 2015 [Page 6] Internet-Draft DOIC October 2014 be true for report types defined in future specifications. Documents that introduce new report types MUST describe any limitations on their use across non-supporting agents. 3.1. Piggybacking Principle The overload control AVPs defined in this specification have been designed to be piggybacked on top of existing application message exchanges. This is made possible by adding overload control top level AVPs, the OC-OLR AVP and the OC-Supported-Features AVP as optional AVPs into existing commands when the corresponding Command Code Format (CCF) specification allows adding new optional AVPs (see Section 1.3.4 of [RFC6733]). Reacting nodes indicate support for DOIC by including the OC- Supported-Features AVP all request messages originated or relayed by the Diameter node. Reporting nodes indicate support for DOIC by including the OC- Supported-Features AVP in all answer messages originated or relayed by the Diameter node. Reporting nodes also include overload reports using the OC-OLR AVP in answer messages. Note: There is no new Diameter application defined to carry overload related AVPs. The DOIC AVPs are carried in existing Diameter application messages. Note that the overload control solution does not have fixed server and client roles. The DOIC node role is determined based on the message type: whether the message is a request (i.e. sent by a "reacting node") or an answer (i.e. send by a "reporting node"). Therefore, in a typical "client-server" deployment, the "client" MAY report its overload condition to the "server" for any server initiated message exchange. An example of such is the server requesting a re-authentication from a client. 3.2. DOIC Capability Announcement The DOIC solutions supports the ability for Diameter nodes to determine if other nodes in the path of a request support the solution. This capability is refered to as DOIC Capability Announcement (DCA) and is separate from Diameter Capability Exchange. The DCA mechanism is built around the piggybacking principle used for transporting Diameter overload AVPs. This includes both DCA AVPs and AVPs associated with Diameter overload reports. This allows for the DCA AVPs to be carried across Diameter nodes that do not support the DOIC solution. Korhonen, et al. Expires April 24, 2015 [Page 7] Internet-Draft DOIC October 2014 The DCA mechanism uses the OC-Supported-Features AVPs to indicate the Diameter overload features supported. The first node in the path of a Diameter request that supports the DOIC solution inserts the OC-Supported-Feature AVP in the request message. This includes an indication that it supports the loss overload abatement algorithm defined in this specification (see Section 5). This insures that there is at least one commonly supported overload abatement algorithm between the reporting node and the reacting nodes in the path of the request. DOIC must support deployments where Diameter Clients and/or Diameter servers do not support the DOIC solution. In this scenario, it is assumed that Diameter Agents that support the DOIC solution will handle overload abatement for the non supporting clients. In this case the DOIC agent will insert the OC- Supporting-Features AVP in requests that do not already contain one, telling the reporting node that there is a DOIC node that will handle overload abatement. The reporting node inserts the OC-Supported-Feature AVP in all answer messages to requests that contained the OC-Supported-Feature AVP. The contents of the reporting node's OC-Supported-Feature AVP indicate the set of Diameter overload features supported by the reporting node with one exception. The reporting node only includes an indication of support for one overload abatement algorithm. This is the algorithm that the reporting node intends to use should it enter an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports. Note that the loss algorithm defined in this document is a stateless abatement algorithm. As a result it does not require any actions by reacting nodes prior to the receipt of an overload report. Stateful abatement algorithms that base the abatement logic on a history of request messages sent might require reacting nodes to maintain state to insure that overload reports can be properly handled. The individual features supported by the DOIC nodes are indicated in the OC-Feature-Vector AVP. Any semantics associated with the features will be defined in extension specifications that introduce the features. The DCA mechanism must also support the scenario where the set of features supported by the sender of a request and by agents in the path of a request differ. In this case, the agent updates the OC- Korhonen, et al. Expires April 24, 2015 [Page 8] Internet-Draft DOIC October 2014 Supported-Feature AVP to reflect the mixture of the two sets of supported features. The logic to determine the content of the modified OC-Supported- Feature AVP is out-of-scope for this specification and is left to implementation decisions. Care must be taken in doing so not to introduce interoperability issues for downstream or upstream DOIC nodes. 3.3. DOIC Overload Condition Reporting As with DOIC Capability Announcement, Overload Condition Reporting uses new AVPs (Section 6.3) to indicate an overload condition. The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP includes the type of report, an overload report ID, the length of time that the report is valid and abatement algorithm specific AVPs. Two types of overload reports are defined in this document, host reports and realm reports. Host reports apply to traffic that is sent to a specific Diameter host. The applies to requests that contain the Destination-Host AVP that contains a DiameterIdentity that matches that of the overload report. These requests are referred to as host-routed requests. A host report also applies to realm-routed requests, requests that do not have a Destination-Host AVP, when the selected route for the request is a connection to the impacted host. Realm reports apply to realm-routed requests for a specific realm as indicated in the Destination-Realm AVP. Reporting nodes are responsible for determining the need for a reduction of traffic. The method for making this determination is implementation specific and depend on the type of overload report being generated. A host report, for instance, will generally be generated by tracking utilization of resources required by the host to handle transactions for the the Diameter application. A realm report will generally impact the traffic sent to multiple hosts and, as such, will typically require tracking the capacity of the servers able to handle realm-routed requests for the application. Once a reporting node determines the need for a reduction in traffic, it uses the DOIC defined AVPs to report on the condition. These AVPs are included in answer messages sent or relayed by the reporting node. The reporting node indicates the overload abatement algorithm that is to be used to handle the traffic reduction in the OC- Korhonen, et al. Expires April 24, 2015 [Page 9] Internet-Draft DOIC October 2014 Supported-Features AVP. The OC-OLR AVP is used to communicate information about the requested reduction. Reacting nodes, upon receipt of an overload report, are responsible for applying the abatement algorithm to traffic impacted by the overload report. The method used for that abatement is dependent on the abatement algorithm. The loss abatement algorithm is defined in this document (Section 5). Other abatement algorithms can be defined in extensions to the DOIC solutions. As the conditions that lead to the generation of the overload report change the reporting node can send new overload reports requesting greater reduction if the condition gets worse or less reduction if the condition improves. The reporting node sends an overload report with a duration of zero to indicate that the overlaod condition has ended and use of the abatement algorithm is no longer needed. The reacting node also determines when the overload report expires based on the OC-Validaty-Duration AVP in the overload report and stops applying the abatement algorithm when the report expires. 3.4. DOIC Extensibility The DOIC solutions is designed to be extensible. This extensibility is based on existing Diameter based extensibility mechanisms. There are multiple categories of extensions that are expected. This includes the definition of new overload abatement algorithms, the definition of new report types and new definitions of the scope of messages impacted by an overload report. The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes to communicate supported features. The specific features supported by the DOIC node are indicated in the OC-Feature-Vector AVP. DOIC extensions must define new values for the OC-Feature-Vector AVP. DOIC extensions also have the ability to add new AVPs to the OC- Supported-Features AVP, if additional information about the new feature is required to be communicate. Overload abatement algorithms use the OC-OLR AVP to communicate overload occurances. This AVP can also be extended to add new AVPs allowing a reporting nodes to communicate additional information about handling an overload condition. If necessary, new extensions can also define new top level AVPs. It is, however, recommended that DOIC extensions use the OC-Supported- Features and OC-OLR to carry all DOIC related AVPs. Korhonen, et al. Expires April 24, 2015 [Page 10] Internet-Draft DOIC October 2014 3.5. Simplified Example Architecture Figure 1 illustrates the simplified architecture for Diameter overload information conveyance. Realm X Same or other Realms <--------------------------------------> <----------------------> +--^-----+ : (optional) : |Diameter| : : |Server A|--+ .--. : +---^----+ : .--. +--------+ | _( `. : |Diameter| : _( `. +---^----+ +--( )--:-| Agent |-:--( )--|Diameter| +--------+ | ( ` . ) ) : +-----^--+ : ( ` . ) ) | Client | |Diameter|--+ `--(___.-' : : `--(___.-' +-----^--+ |Server B| : : +---^----+ : : End-to-end Overload Indication 1) <-----------------------------------------------> Diameter Application Y Overload Indication A Overload Indication A' 2) <----------------------> <----------------------> standard base protocol standard base protocol Figure 1: Simplified architecture choices for overload indication delivery In Figure 1, the Diameter overload indication can be conveyed (1) end-to-end between servers and clients or (2) between servers and Diameter agent inside the realm and then between the Diameter agent and the clients when the Diameter agent acting as back-to-back-agent for DOIC purposes. 4. Solution Procedures This section outlines the normative behavior associated with the DOIC solution. Korhonen, et al. Expires April 24, 2015 [Page 11] Internet-Draft DOIC October 2014 4.1. Capability Announcement This section defines DOIC Capability Announcement (DCA) behavior. The DCA procedures are used to indicate support for DOIC and support for DOIC features. The DOIC features include overload abatement algorithms supported. It might also include new report types or other extensions documented in the future. Diameter nodes indicate support for DOIC by including the OC- Supported-Features AVP in messages sent or handled by the node. Diameter agents that support DOIC MUST ensure that all messages have the OC-Supporting-Features AVP. If a message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP. If the message already has the AVP then the agent either leaves it unchanged in the relayed message or modifies it to reflect a mixed set of DOIC features. 4.1.1. Reacting Node Behavior A reacting node MUST include the OC-Supported-Features AVP in all request messages. A reacting node MAY include the OC-Feature-Vector AVP with an indication of the loss algorithm. A reacting node MUST include the OC-Feature-Vector AVP to indicate support for abatement algorithms in addition to the loss algorithm. A reacting node SHOULD indicate support for all other DOIC features it supports. An OC-Supported-Features AVP in answer messages indicates there is a reporting node for the transaction. The reacting node MAY take action based on the features indicated in the OC-Feature-Vector AVP. Note that the loss abatement algorithm is the only feature described in this document and it does not require action to be taken when there is an active overload report. This behavior is described in Section 4.2 and Section 5. 4.1.2. Reporting Node Behavior Upon receipt of a request message, a reporting node determines if there is a reacting node for the transaction based on the presence of the OC-Supported-Features AVP. Korhonen, et al. Expires April 24, 2015 [Page 12] Internet-Draft DOIC October 2014 Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality supported by reacting node(s). The reporting node then acts accordingly for the subsequent answer messages it initiates. If the reqeust message contains an OC-Supported-Features AVP then the reporting node MUST include the OC-Supported-Features AVP in the answer message for that transaction. The reporting node MUST indicate support for one and only one abatement algorithm in the OC-Feature-Vector AVP. The abatement algorithm included MUST be from the set of abatement algorithms contained in the request messages OC-Supported-Features AVP. The abatement algorithm included indicates the abatement algorithm the reporting node wants the reacting node to use when the reporting node enters an overload condition. The reporting node MUST NOT change the selected algorithm during a period of time that it is in an overload condition and, as a result, is sending OC-OLR AVPs in answer messages. The reporting node SHOULD indicate support for other DOIC features it supports and that apply to the transaction. Note that not all DOIC features will apply to all Diameter applications or deployment scenarios. The features included in the OC-Feature-Vector AVP is based on local reporting node policy. The reporting node MUST NOT include the OC-Supported-Features AVP, OC-OLR AVP or any other overload control AVPs defined in extension drafts in response messages for transactions where the request message does not include the OC-Supported-Features AVP. Lack of the OC-Supported-Features AVP in the request message indicates that there is no reacting node for the transaction. An agent MAY modify the OC-Supported-Features AVP carried in answer messages. 4.2. Overload Report Processing 4.2.1. Overload Control State Both reacting and reporting nodes maintain an overload control state (OCS) for active overload reports. Korhonen, et al. Expires April 24, 2015 [Page 13] Internet-Draft DOIC October 2014 4.2.1.1. Overload Control State for Reacting Nodes A reacting node maintains the following OCS per supported Diameter application: o A host-type Overload Control State for each Destination-Host towards which it sends host-type requests and o A realm-type Overload Control State for each Destination-Realm towards which it sends realm-type requests. A host-type Overload Control State may be identified by the pair of Application-Id and Destination-Host. A realm-type Overload Control State may be identified by the pair of Application-Id and Destination-Realm. The host-type/realm-type Overload Control State for a given pair of Application and Destination-Host / Destination- Realm could include the following information: o Sequence number (as received in OC-OLR) o Time of expiry (deviated from validity duration as received in OC- OLR and time of reception) o Selected Abatement Algorithm (as received in OC-Supported- Features) o Algorithm specific input data (as received within OC-OLR, e.g. Reduction Percentage for Loss) 4.2.1.2. Overload Control States for Reporting Nodes A reporting node maintains per supported Diameter application and per supported (and eventually selected) Abatement Algorithm an Overload Control State. An Overload Control State may be identified by the pair of Application-Id and supported Abatement Algorithm. The Overload Control State for a given pair of Application and Abatement Algorithm could include the information: o Report type o Sequence number o Validity Duration and Expiry Time Korhonen, et al. Expires April 24, 2015 [Page 14] Internet-Draft DOIC October 2014 o Algorithm specific input data (e.g. Reduction Percentage for Loss) 4.2.1.3. Maintaining Overload Control State Reacting nodes create a host-type OCS identified by OCS-Id = (app- id,host-id) when receiving an answer message of application app-id containing an Orig-Host of host-id and a host-type OC-OLR AVP unless such host-type OCS already exists. Reacting nodes create a realm-type OCS identified by OCS-Id = (app- id,realm-id) when receiving an answer message of application app-id containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP unless such realm type OCS already exists. Reacting nodes delete an OCS when it expires (i.e. when current time minus reception time is greater than validity duration). Reacting nodes also delete on OCS with an updated OLR is received with a validity duration of zero. Reacting nodes update the host-type OCS identified by OCS-Id = (app- id,host-id) when receiving an answer message of application app-id containing an Orig-Host of host-id and a host-type OC-OLR AVP with a sequence number higher than the stored sequence number. Reacting nodes update the realm-type OCS identified by OCS-Id = (app- id,realm-id) when receiving an answer message of application app-id containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP with a sequence number higher than the stored sequence number. Reacting nodes do not delete an OCS when receiving an answer message that does not contain an OC-OLR AVP (i.e. absence of OLR means "no change"). Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a request of application app-id containing an OC- Supported-Features AVP indicating support of the Abatement Algorithm Alg (which the reporting node selects) while being overloaded, unless such OCS already exists. Reporting nodes delete an OCS when it expires. Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the need to modify the requested amount of application app-id traffic reduction. Korhonen, et al. Expires April 24, 2015 [Page 15] Internet-Draft DOIC October 2014 4.2.2. Reacting Node Behavior Once a reacting node receives an OC-OLR AVP from a reporting node, it applies traffic abatement based on the selected algorithm with the reporting node and the current overload condition. The reacting node learns the reporting node supported abatement algorithms directly from the received answer message containing the OC-Supported-Features AVP. The received OC-Supported-Features AVP does not change the existing overload condition and/or traffic abatement algorithm settings if the OC-Sequence-Number AVP contains a value that is equal to the previously received/recorded value. If the OC-Supported-Features AVP is received for the first time for the reporting node or the OC- Sequence-Number AVP value is less than the previously received/ recorded value (and is outside the valid overflow window), then the sequence number is stale (e.g. an intentional or unintentional replay) and SHOULD be silently discarded. As described in Section 6.3, the OC-OLR AVP contains the necessary information for the overload condition on the reporting node. From the OC-Report-Type AVP contained in the OC-OLR AVP, the reacting node learns whether the overload condition report concerns a specific host (as identified by the Origin-Host AVP of the answer message containing the OC-OLR AVP) or the entire realm (as identified by the Origin-Realm AVP of the answer message containing the OC-OLR AVP). The reacting node learns the Diameter application to which the overload report applies from the Application-ID of the answer message containing the OC-OLR AVP. The reacting node MUST use this information as an input for its traffic abatement algorithm. The idea is that the reacting node applies different handling of the traffic abatement, whether sent request messages are targeted to a specific host (identified by the Diameter-Host AVP in the request) or to any host in a realm (when only the Destination-Realm AVP is present in the request). Note that future specifications MAY define new OC-Report-Type AVP values that imply different handling of the OC-OLR AVP. For example, in a form of new additional AVPs inside the Grouped OC-OLR AVP that would define report target in a finer granularity than just a host. If the OC-OLR AVP is received for the first time, the reacting node MUST create overload control state associated with the related realm or a specific host in the realm identified in the message carrying the OC-OLR AVP, as described in Section 4.2.1. If the value of the OC-Sequence-Number AVP contained in the received OC-OLR AVP is equal to or less than the value stored in an existing Korhonen, et al. Expires April 24, 2015 [Page 16] Internet-Draft DOIC October 2014 overload control state, the received OC-OLR AVP SHOULD be silently discarded. If the value of the OC-Sequence-Number AVP contained in the received OC-OLR AVP is greater than the value stored in an existing overload control state or there is no previously recorded sequence number, the reacting node MUST update the overload control state associated with the realm or the specific node in the realm. When an overload control state is created or updated, the reacting node MUST apply the traffic abatement requested in the OC-OLR AVP using the algorithm announced in the OC-Supported-Features AVP contained in the received answer message along with the OC-OLR AVP. The validity duration of the overload information contained in the OC-OLR AVP is either explicitly indicated in the OC-Validity-Duration AVP or is implicitly equals to the default value if the OC-Validity- Duration AVP is absent. The reacting node MUST maintain the validity duration in the overload control state. Once the validity duration times out, the reacting node MUST assume the overload condition reported in a previous OC-OLR AVP has ended. A value of zero ("0") received in the OC-Validity-Duration in an updated overload report indicates that the overload condition has ended and that the overload state is no longer valid. In the case that the validity duration expires or is explicitly signaled as being no longer valid the state associated with the overload report MUST be removed and any abatement associated with the overload report MUST be ended in a controlled fashion. After removing the overload state the sequence number MUST NOT be used for future comparisons of sequence numbers. 4.2.3. Reporting Node Behavior A reporting node is a Diameter node inserting an OC-OLR AVP in a Diameter message in order to inform a reacting node about an overload condition and request Diameter traffic abatement. The operation on the reporting node is straight forward. The reporting node learns the capabilities of the reacting node when it receives the OC-Supported-Features AVP as part of any Diameter request message. Since the loss abatement algorithm Section 5 is mandatory to implement DOIC can always be enabled between these DOIC nodes See Section 4.1 for further discussion on the capability and feature announcement. When a traffic reduction is required due to an overload condition and the overload control solution is supported by the sender of the Korhonen, et al. Expires April 24, 2015 [Page 17] Internet-Draft DOIC October 2014 Diameter request, the reporting node SHOULD include an OC-Supported- Features AVP and an OC-OLR AVP in the corresponding Diameter answer. A reporting node MAY choose to not resend an overload report to a reacting node if it can guarantee that this overload report is already active in the reacting node. Note - In some cases (e.g. when there are one or multiple agents in the path between reporting and reacting nodes, or when overload reports are discarded by reacting nodes) the reporting node may not be able to guarantee that the reacting node has received the report. The OC-OLR AVP contains the required traffic reduction and the OC- Supported-Features AVP indicates the traffic abatement algorithm to apply. This algorithm MUST be one of the algorithms advertised by the request sender. A reporting node MUST only send overload reports of a type advertised as supported by the reacting node. Note that a reacting node advertises support for the host and realm report types by including the OC-Supported-Features AVP in the request. Support for other report types must be explicitly indicated by a new feature bit in the OC-Feature-Vector AVP. If OLR is for a new overload condition and there is no unexpired overload report for previous overload conditions at any reacting node then the reporting node MAY set the sequence number to any value. The reporting node MAY update the overload report with new reduction percentages. The reporting node MAY extend the validatity duration for an existing overload report by sending a OLR with either the same or a new validity duration value. When sending an overload report with new values in any of the sub AVPs for an existing overload condition, the reporting node MUST increase the sequence number in the new OLR sent. When generating sequence numbers for new overload conditions, the new sequence number MUST be greater than any sequence number in an active (unexpired) overload report previously sent by the reporting node. This property MUST hold over a reboot of the reporting node. A reporting node MAY rely on the OC-Validity-Duration AVP values for the implicit overload control state cleanup on the reacting node. Korhonen, et al. Expires April 24, 2015 [Page 18] Internet-Draft DOIC October 2014 However, it is RECOMMENDED that the reporting node always explicitly indicates the end of a overload condition. The reporting node SHOULD indicate the end of an overload occurrence by sending a new OLR with OC-Validity-Duration set to a value of zero ("0"). The reporting node SHOULD insure that all reacting nodes receive the updated overload report. When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes. Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the OLR applies. That is, the same candidate set of messages SHOULD NOT be throttled multiple times. However, when the reporting node sends and OLR downstream, it MAY still be responsible to apply other abatement methods, such as diversion, or request throttling requests for other reasons. For example, an agent or server might have a configured rate limit for each client, and throttle requests that exceed that limit, even if such requests had already been candidates for throttling by downstream nodes. All OLRs sent have an expiration time calculated by adding the validity-duration contained in the OLR to the time the message was sent. Transit time for the OLR can be safely ignored. The reporting node can ensure that all reacting nodes have received the OLR by continuing to send it in answer messages until the expiration time for all OLRs sent for that overload contition have expired. This document assumes that there is a single source for realm-reports for a given realm, or that if multiple nodes can send realm reports, that each such node has full knowledge of the overload state of the entire realm. A reacting node cannot distinguish between receiving realm-reports from a single node, or from multiple nodes. If multiple such nodes exist, they MUST ensure that realm-reports are kept in sync. This includes synchronizing the sequence numbers as well as the reported overload state. The method of doing so is up to the implementation. One way to keep the sequence numbers in sync is to generate the sequence numbers based on system time. 4.3. Protocol Extensibility The overload control solution can be extended, e.g. with new traffic abatement algorithms, new report types or other new functionality. Korhonen, et al. Expires April 24, 2015 [Page 19] Internet-Draft DOIC October 2014 When defining a new extension a new feature bit MUST be defined for the OC-Feature-Vector. This feature bit is used to communicate support for the new feature. The extention may also define new AVPs for use in DOIC Capability Anouncement and for use in DOIC Overload reporting. These new AVP should be defined to be extensions to the OC-Supported-Features and OC-OLR AVPs defined in this document. It should be noted that [RFC6733] defined Grouped AVP extension mechanisms apply. This allows, for example, defining a new feature that is mandatory to be understood even when piggybacked on an existing applications. The handling of feature bits in the OC-Feature-Vector AVP that are not associated with overload abatement algorithms MUST be specified by the extensions that define the features. When defining new report type values, the corresponding specification MUST define the semantics of the new report types and how they affect the OC-OLR AVP handling. The specification MUST also reserve a corresponding new feature, see the OC-Supported-Features and OC- Feature-Vector AVPs. The OC-OLR AVP can be expanded with optional sub-AVPs only if a legacy implementation can safely ignore them without breaking backward compatibility for the given OC-Report-Type AVP value implied report handling semantics. If the new sub-AVPs imply new semantics for handling the indicated report type, then a new OC-Report-Type AVP value MUST be defined. New features (feature bits in the OC-Feature-Vector AVP) and report types (in the OC-Report-Type AVP) MUST be registered with IANA. As with any Diameter specification, new AVPs MUST also be registered with IANA. See Section 8 for the required procedures. 5. Loss Algorithm This section documents the Diameter overload loss abatement algorithm. 5.1. Overview The DOIC specification supports the ability for multiple overload abatement algorithms to be specified. The abatement algorithm used for any instance of overload is determined by the Diameter Overload Capability Announcement process documented in Section 4.1. Korhonen, et al. Expires April 24, 2015 [Page 20] Internet-Draft DOIC October 2014 The loss algorithm described in this section is the default algorithm that must be supported by all Diameter nodes that support DOIC. The loss algorithm is designed to be a straightforward and stateless overload abatement algorithm. It is used by reporting nodes to request a percentage reduction in the amount of traffic sent. The traffic impacted by the requested reduction depends on the type of overload report. Reporting nodes use a strategy of applying abatement logic to the requested percentage of request messages sent (or handled in the case of agents) by the reacting node that are impacted by the overload report. From a conceptual level, the logic at the reacting node could be outlined as follows. In this discussion assume that the reacting node is also the sending node. 1. An overload report is received and the associated overload state is saved by the reacting node. 2. A new Diameter request is generated by the application running on the reacting node. 3. The reacting node determines that an active overload report applies to the request. 4. The reacting node determines if abatement should be applied to the request. One approach that could be taken would be to select a random number between 1 and 100. If the random number is less than the indicated reduction percentage then the request is given abatement treatment, otherwise the request is given normal routing treatment. 5.2. Reporting Node Behavior The method a reporting nodes uses to determine the amount of traffic reduction required to address an overload condition is an implementation decision. When a reporting node that has selected the loss abatement algorithm determines the need to request a traffic reduction it includes an OC- OLR AVP in response messages as described in Section 4.2.3. The reporting node must indicate a percentage reduction in the OC- Reduction-Percentage AVP. Korhonen, et al. Expires April 24, 2015 [Page 21] Internet-Draft DOIC October 2014 The reporting node may change the reduction percentage in subsequent overload reports. When doing so the reporting node must conform to overload report handing specified in Section 4.2.3. When the reporting node determines it no longer needs a reduction in traffic the reporting node should send an overload report indicating the overload report is no longer valid, as specified in Section 4.2.3. 5.3. Reacting Node Behavior The method a reacting node uses to determine which request messages are given abatement treatment is an implementation decision. When receiving an OC-OLR in an answer message where the algorithm indicated in the OC-Supported-Features AVP is the loss algorithm, the reacting node must attempt to apply abatement treatment to the requested percentage of request messages sent. Note: the loss algorithm is a stateless algorithm. As a result, the reacting node does not guarantee that there will be an absolute reduction in traffic sent. Rather, it guarantees that the requested percentage of new requests will be given abatement treatment. If reacting node comes out of the 100 percent traffic reduction as a result of the overload report timing out, the following concerns are RECOMMENDED to be applied. The reacting node sending the traffic should be conservative and, for example, first send "probe" messages to learn the overload condition of the overloaded node before converging to any traffic amount/rate decided by the sender. Similar concerns apply in all cases when the overload report times out unless the previous overload report stated 0 percent reduction. If the reacting node does not receive a an OLR in messages sent to the formally overloaded node then the reacting node should slowly increase the rate of traffic sent to the overloaded node. It is suggested that the reacting node decrease the amount of traffic given abatement treatment by 20% each second until the reduction is completely removed and no traffic is given abatement treatment. The goal of this behavior is to reduce the probability of overload condition thrashing where an immediate transition from 100% reduction to 0% reduction results in the reporting node moving quickly back into an overload condition. Korhonen, et al. Expires April 24, 2015 [Page 22] Internet-Draft DOIC October 2014 6. Attribute Value Pairs This section describes the encoding and semantics of the Diameter Overload Indication Attribute Value Pairs (AVPs) defined in this document. When added to existing commands, both OC-Feature-Vector and OC-OLR AVPs SHOULD have the M-bit flag cleared to avoid backward compatibility issues. A new application specification can incorporate the overload control mechanism specified in this document by making it mandatory to implement for the application and referencing this specification normatively. In such a case, the rules for handling of the M-bit must follow the guidance in [RFC6733]. It is the responsibility of the Diameter application designers to define how overload control mechanisms works on that application. 6.1. OC-Supported-Features AVP The OC-Supported-Features AVP (AVP code TBD1) is type of Grouped and serves two purposes. First, it announces a node's support for the DOIC solution in general. Second, it contains the description of the supported DOIC features of the sending node. The OC-Supported- Features AVP MUST be included in every Diameter message a DOIC supporting node sends. OC-Supported-Features ::= < AVP Header: TBD1 > [ OC-Feature-Vector ] * [ AVP ] The OC-Feature-Vector sub-AVP is used to announce the DOIC features supported by the DOIC node, in the form of a flag bits field in which each bit announces one feature or capability supported by the node (see Section 6.2). The absence of the OC-Feature-Vector AVP indicates that only the default traffic abatement algorithm described in this specification is supported. 6.2. OC-Feature-Vector AVP The OC-Feature-Vector AVP (AVP code TBD6) is type of Unsigned64 and contains a 64 bit flags field of announced capabilities of a DOIC node. The value of zero (0) is reserved. The following capabilities are defined in this document: OLR_DEFAULT_ALGO (0x0000000000000001) Korhonen, et al. Expires April 24, 2015 [Page 23] Internet-Draft DOIC October 2014 When this flag is set by the DOIC node it means that the default traffic abatement (loss) algorithm is supported. 6.3. OC-OLR AVP The OC-OLR AVP (AVP code TBD2) is type of Grouped and contains the information necessary to convey an overload report. The OC-OLR AVP does not explicitly contain all information needed by the reacting node to decide whether a subsequent request must undergo a throttling process with the received reduction percentage. The value of the OC- Report-Type AVP within the OC-OLR AVP indicates which implicit information is relevant for this decision (see Section 6.6). The application the OC-OLR AVP applies to is the same as the Application- Id found in the Diameter message header. The host or realm the OC- OLR AVP concerns is determined from the Origin-Host AVP and/or Origin-Realm AVP found in the encapsulating Diameter command. The OC-OLR AVP is intended to be sent only by a reporting node. OC-OLR ::= < AVP Header: TBD2 > < OC-Sequence-Number > < OC-Report-Type > [ OC-Reduction-Percentage ] [ OC-Validity-Duration ] * [ AVP ] Note that if a Diameter command were to contain multiple OC-OLR AVPs they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs with unknown values SHOULD be silently discarded and the event SHOULD be logged. 6.4. OC-Sequence-Number AVP The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64. Its usage in the context of overload control is described in Section 4.2. From the functionality point of view, the OC-Sequence-Number AVP MUST be used as a non-volatile increasing counter for a sequence of overload reports between two DOIC nodes for the same overload occurrence. The sequence number is only required to be unique between two DOIC nodes. Sequence numbers are treated in a uni- directional manner, i.e. two sequence numbers on each direction between two DOIC nodes are not related or correlated. When generating sequence numbers, the new sequence number MUST be greater than any sequence number in an active, unexpired, overload Korhonen, et al. Expires April 24, 2015 [Page 24] Internet-Draft DOIC October 2014 report previously sent by the reporting node. This property MUST hold over a reboot of the reporting node. 6.5. OC-Validity-Duration AVP The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and indicates in seconds the validity time of the overload report. The number of seconds is measured after reception of the first OC-OLR AVP with a given value of OC-Sequence-Number AVP. The default value for the OC-Validity-Duration AVP is 5 (i.e., 5 seconds). When the OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value applies. Validity duration with values above 86400 (i.e.; 24 hours) MUST NOT be used. Invalid duration values are treated as if the OC-Validity-Duration AVP were not present and result in the default value being used. A timeout of the overload report has specific concerns that need to be taken into account by the DOIC node acting on the earlier received overload report(s). Section 6.7 discusses the impacts of timeout in the scope of the traffic abatement algorithms. When a reporting node has recovered from overload, it SHOULD invalidate any existing overload reports in a timely matter. This can be achieved by sending an updated overload report (meaning the OLR contains a new sequence number) with the OC-Validity-Duration AVP value set to zero ("0"). If the overload report is about to expire naturally, the reporting node MAY choose to simply let it do so. A reacting node MUST invalidate and remove an overload report that expires without an explicit overload report containing an OC- Validity-Duration value set to zero ("0"). 6.6. OC-Report-Type AVP The OC-Report-Type AVP (AVP code TBD5) is type of Enumerated. The value of the AVP describes what the overload report concerns. The following values are initially defined: 0 A host report. The overload treatment should apply to requests for which all of the following conditions are true: Either the Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP; or the Destination-Host is not present in the request but the value of peer identity associated with the connection used to send the request matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. Korhonen, et al. Expires April 24, 2015 [Page 25] Internet-Draft DOIC October 2014 The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. 1 A realm report. The overload treatment should apply to requests for which all of the following conditions are true: The Destination-Host AVP is absent in the request. The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. The OC-Report-Type AVP is envisioned to be useful for situations where a reacting node needs to apply different overload treatments for different "types" of overload. For example, the reacting node(s) might need to throttle differently requests sent to a specific server (identified by the Destination-Host AVP in the request) and requests that can be handled by any server in a realm. 6.7. OC-Reduction-Percentage AVP The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32 and describes the percentage of the traffic that the sender is requested to reduce, compared to what it otherwise would send. The OC-Reduction-Percentage AVP applies to the default (loss) algorithm specified in this specification. However, the AVP can be reused for future abatement algorithms, if its semantics fit into the new algorithm. The value of the Reduction-Percentage AVP is between zero (0) and one hundred (100). Values greater than 100 are ignored. The value of 100 means that all traffic is to be throttled, i.e. the reporting node is under a severe load and ceases to process any new messages. The value of 0 means that the reporting node is in a stable state and has no need for the reacting node to apply any traffic abatement. The default value of the OC-Reduction-Percentage AVP is 0. When the OC-Reduction-Percentage AVP is not present in the overload report, the default value applies. Korhonen, et al. Expires April 24, 2015 [Page 26] Internet-Draft DOIC October 2014 6.8. Attribute Value Pair flag rules +---------+ |AVP flag | |rules | +----+----+ AVP Section | |MUST| Attribute Name Code Defined Value Type |MUST| NOT| +--------------------------------------------------+----+----+ |OC-Supported-Features TBD1 x.x Grouped | | V | +--------------------------------------------------+----+----+ |OC-OLR TBD2 x.x Grouped | | V | +--------------------------------------------------+----+----+ |OC-Sequence-Number TBD3 x.x Unsigned64 | | V | +--------------------------------------------------+----+----+ |OC-Validity-Duration TBD4 x.x Unsigned32 | | V | +--------------------------------------------------+----+----+ |OC-Report-Type TBD5 x.x Enumerated | | V | +--------------------------------------------------+----+----+ |OC-Reduction | | | | -Percentage TBD8 x.x Unsigned32 | | V | +--------------------------------------------------+----+----+ |OC-Feature-Vector TBD6 x.x Unsigned64 | | V | +--------------------------------------------------+----+----+ As described in the Diameter base protocol [RFC6733], the M-bit setting for a given AVP is relevant to an application and each command within that application that includes the AVP. The Diameter overload control AVPs SHOULD always be sent with the M-bit cleared when used within existing Diameter applications to avoid backward compatibility issues. Otherwise, when reused in newly defined Diameter applications, the DOC related AVPs SHOULD have the M-bit set. 7. Error Response Codes When a DOIC node rejects a Diameter request due to throttling, the DOIC node needs to select the appropriate error response code. This determination is made based on the probability of the request succeeding if retried on a different path. The DIAMETER_TOO_BUSY response code SHOULD be used when the request is likely to succeed on a different path. For instance, if the request arrived at the reporting node without a Destination-Host AVP then the reporting node might determine Korhonen, et al. Expires April 24, 2015 [Page 27] Internet-Draft DOIC October 2014 that there is an alternative Diameter node that could successfully process the request and that retrying the transaction would not negatively impact the reporting node. The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to indicate that the request should not be retried. This is used when the request is not likely to succeed on a different path and retrying would consume valuable resources during an occurance of overload. For instance, if the request arrived at the reporting node with a Destination-Host AVP populated with its own Diameter identity then the reporting node can assume that retrying the request would result in it coming to the same reporting node. A second example is when an agent that supports the DOIC solution is preforming the role of a reacting node for a non supporting client. Requests that are rejected as a result of DOIC throttling in this scenario would generally be rejected with a DIAMETER_UNABLE_TO_COMPLY response code. 8. IANA Considerations 8.1. AVP codes New AVPs defined by this specification are listed in Section 6. All AVP codes allocated from the 'Authentication, Authorization, and Accounting (AAA) Parameters' AVP Codes registry. 8.2. New registries Three new registries are needed under the 'Authentication, Authorization, and Accounting (AAA) Parameters' registry. Section 6.2 defines a new "Overload Control Feature Vector" registry including the initial assignments. New values can be added into the registry using the Specification Required policy [RFC5226]. See Section 6.2 for the initial assignment in the registry. Section 6.6 defines a new "Overload Report Type" registry with its initial assignments. New types can be added using the Specification Required policy [RFC5226]. 9. Security Considerations This mechanism gives Diameter nodes the ability to request that downstream nodes send fewer Diameter requests. Nodes do this by exchanging overload reports that directly affect this reduction. This exchange is potentially subject to multiple methods of attack, Korhonen, et al. Expires April 24, 2015 [Page 28] Internet-Draft DOIC October 2014 and has the potential to be used as a Denial-of-Service (DoS) attack vector. Overload reports may contain information about the topology and current status of a Diameter network. This information is potentially sensitive. Network operators may wish to control disclosure of overload reports to unauthorized parties to avoid its use for competitive intelligence or to target attacks. Diameter does not include features to provide end-to-end authentication, integrity protection, or confidentiality. This may cause complications when sending overload reports between non- adjacent nodes. 9.1. Potential Threat Modes The Diameter protocol involves transactions in the form of requests and answers exchanged between clients and servers. These clients and servers may be peers, that is,they may share a direct transport (e.g. TCP or SCTP) connection, or the messages may traverse one or more intermediaries, known as Diameter Agents. Diameter nodes use TLS, DTLS, or IPSec to authenticate peers, and to provide confidentiality and integrity protection of traffic between peers. Nodes can make authorization decisions based on the peer identities authenticated at the transport layer. When agents are involved, this presents an effectively hop-by-hop trust model. That is, a Diameter client or server can authorize an agent for certain actions, but it must trust that agent to make appropriate authorization decisions about its peers, and so on. Since confidentiality and integrity protection occurs at the transport layer. Agents can read, and perhaps modify, any part of a Diameter message, including an overload report. There are several ways an attacker might attempt to exploit the overload control mechanism. An unauthorized third party might inject an overload report into the network. If this third party is upstream of an agent, and that agent fails to apply proper authorization policies, downstream nodes may mistakenly trust the report. This attack is at least partially mitigated by the assumption that nodes include overload reports in Diameter answers but not in requests. This requires an attacker to have knowledge of the original request in order to construct a response. Therefore, implementations SHOULD validate that an answer containing an overload report is a properly constructed response to a pending request prior to acting on the overload report. Korhonen, et al. Expires April 24, 2015 [Page 29] Internet-Draft DOIC October 2014 A similar attack involves an otherwise authorized Diameter node that sends an inappropriate overload report. For example, a server for the realm "example.com" might send an overload report indicating that a competitor's realm "example.net" is overloaded. If other nodes act on the report, they may falsely believe that "example.net" is overloaded, effectively reducing that realm's capacity. Therefore, it's critical that nodes validate that an overload report received from a peer actually falls within that peer's responsibility before acting on the report or forwarding the report to other peers. For example, an overload report from an peer that applies to a realm not handled by that peer is suspect. An attacker might use the information in an overload report to assist in certain attacks. For example, an attacker could use information about current overload conditions to time a DoS attack for maximum effect, or use subsequent overload reports as a feedback mechanism to learn the results of a previous or ongoing attack. 9.2. Denial of Service Attacks Diameter overload reports can cause a node to cease sending some or all Diameter requests for an extended period. This makes them a tempting vector for DoS tacks. Furthermore, since Diameter is almost always used in support of other protocols, a DoS attack on Diameter is likely to impact those protocols as well. Therefore, Diameter nodes MUST NOT honor or forward overload reports from unauthorized or otherwise untrusted sources. 9.3. Non-Compliant Nodes When a Diameter node sends an overload report, it cannot assume that all nodes will comply. A non-compliant node might continue to send requests with no reduction in load. Requirement 28 [RFC7068] indicates that the overload control solution cannot assume that all Diameter nodes in a network are necessarily trusted, and that malicious nodes not be allowed to take advantage of the overload control mechanism to get more than their fair share of service. In the absence of an overload control mechanism, Diameter nodes need to implement strategies to protect themselves from floods of requests, and to make sure that a disproportionate load from one source does not prevent other sources from receiving service. For example, a Diameter server might reject a certain percentage of requests from sources that exceed certain limits. Overload control can be thought of as an optimization for such strategies, where downstream nodes never send the excess requests in the first place. However, the presence of an overload control mechanism does not remove the need for these other protection strategies. Korhonen, et al. Expires April 24, 2015 [Page 30] Internet-Draft DOIC October 2014 9.4. End-to End-Security Issues The lack of end-to-end security features makes it far more difficult to establish trust in overload reports that originate from non- adjacent nodes. Any agents in the message path may insert or modify overload reports. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive-trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting Diameter overload control MUST give operators the ability to select which peers are trusted to deliver overload reports, and whether they are trusted to forward overload reports from non-adjacent nodes. The lack of end-to-end confidentiality protection means that any Diameter agent in the path of an overload report can view the contents of that report. In addition to the requirement to select which peers are trusted to send overload reports, operators MUST be able to select which peers are authorized to receive reports. A node MUST not send an overload report to a peer not authorized to receive it. Furthermore, an agent MUST remove any overload reports that might have been inserted by other nodes before forwarding a Diameter message to a peer that is not authorized to receive overload reports. At the time of this writing, the DIME working group is studying requirements for adding end-to-end security [I-D.ietf-dime-e2e-sec-req] features to Diameter. These features, when they become available, might make it easier to establish trust in non-adjacent nodes for overload control purposes. Readers should be reminded, however, that the overload control mechanism encourages Diameter agents to modify AVPs in, or insert additional AVPs into, existing messages that are originated by other nodes. If end-to-end security is enabled, there is a risk that such modification could violate integrity protection. The details of using any future Diameter end-to-end security mechanism with overload control will require careful consideration, and are beyond the scope of this document. 10. Contributors The following people contributed substantial ideas, feedback, and discussion to this document: o Eric McMurry o Hannes Tschofenig Korhonen, et al. Expires April 24, 2015 [Page 31] Internet-Draft DOIC October 2014 o Ulrich Wiehe o Jean-Jacques Trottin o Maria Cruz Bartolome o Martin Dolly o Nirav Salot o Susan Shishufeng 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012. 11.2. Informative References [Cx] 3GPP, , "ETSI TS 129 229 V11.4.0", August 2013. [I-D.ietf-dime-e2e-sec-req] Tschofenig, H., Korhonen, J., Zorn, G., and K. Pillay, "Diameter AVP Level Security: Scenarios and Requirements", draft-ietf-dime-e2e-sec-req-00 (work in progress), September 2013. [PCC] 3GPP, , "ETSI TS 123 203 V11.12.0", December 2013. [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005. Korhonen, et al. Expires April 24, 2015 [Page 32] Internet-Draft DOIC October 2014 [RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009. [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control Requirements", RFC 7068, November 2013. [S13] 3GPP, , "ETSI TS 129 272 V11.9.0", December 2012. Appendix A. Issues left for future specifications The base solution for the overload control does not cover all possible use cases. A number of solution aspects were intentionally left for future specification and protocol work. A.1. Additional traffic abatement algorithms This specification describes only means for a simple loss based algorithm. Future algorithms can be added using the designed solution extension mechanism. The new algorithms need to be registered with IANA. See Sections 6.1 and 8 for the required IANA steps. A.2. Agent Overload This specification focuses on Diameter endpoint (server or client) overload. A separate extension will be required to outline the handling the case of agent overload. A.3. DIAMETER_TOO_BUSY clarifications The current [RFC6733] behavior in a case of DIAMETER_TOO_BUSY is somewhat under specified. For example, there is no information how long the specific Diameter node is willing to be unavailable. A specification updating [RFC6733] should clarify the handling of DIAMETER_TOO_BUSY from the error answer initiating Diameter node point of view and from the original request initiating Diameter node point of view. Further, the inclusion of possible additional information providing AVPs should be discussed and possible be recommended to be used. Appendix B. Deployment Considerations Non supporting agents Due to the way that realm-routed requests are handled in Diameter networks, with the server selection for the request done by an agent, it is recommended that deployments upgrade all agents with Korhonen, et al. Expires April 24, 2015 [Page 33] Internet-Draft DOIC October 2014 direct connections to servers prior to enabling the DOIC solution in the Diameter network. Topology hiding interactions There exist proxies that implement what is refered to as Topology Hiding. This can include cases where the agent modifies the Origin-Host in answer messages. The behavior of the DOIC solution is not well understood when this happens. As such, the DOIC solution does not address this scenario. Appendix C. Considerations for Applications Integrating the DOIC Solution THis section outlines considerations to be taken into account when integrating the DOIC solution into Diameter applications. C.1. Application Classification The following is a classification of Diameter applications and requests. This discussion is meant to document factors that play into decisions made by the Diameter identity responsible for handling overload reports. Section 8.1 of [RFC6733] defines two state machines that imply two types of applications, session-less and session-based applications. The primary difference between these types of applications is the lifetime of Session-Ids. For session-based applications, the Session-Id is used to tie multiple requests into a single session. In session-less applications, the lifetime of the Session-Id is a single Diameter transaction, i.e. the session is implicitly terminated after a single Diameter transaction and a new Session-Id is generated for each Diameter request. For the purposes of this discussion, session-less applications are further divided into two types of applications: Stateless applications: Requests within a stateless application have no relationship to each other. The 3GPP defined S13 application is an example of a stateless application [S13], --> where only a Diameter command is defined between a client and a server and no state is maintained between two consecutive transactions. Korhonen, et al. Expires April 24, 2015 [Page 34] Internet-Draft DOIC October 2014 Pseudo-session applications: Applications that do not rely on the Session-Id AVP for correlation of application messages related to the same session but use other session-related information in the Diameter requests for this purpose. The 3GPP defined Cx application [Cx] is an example of a pseudo-session application. The Credit-Control application defined in [RFC4006] is an example of a Diameter session-based application. The handling of overload reports must take the type of application into consideration, as discussed in Appendix C.2. C.2. Application Type Overload Implications This section discusses considerations for mitigating overload reported by a Diameter entity. This discussion focuses on the type of application. Appendix C.3 discusses considerations for handling various request types when the target server is known to be in an overloaded state. These discussions assume that the strategy for mitigating the reported overload is to reduce the overall workload sent to the overloaded entity. The concept of applying overload treatment to requests targeted for an overloaded Diameter entity is inherent to this discussion. The method used to reduce offered load is not specified here but could include routing requests to another Diameter entity known to be able to handle them, or it could mean rejecting certain requests. For a Diameter agent, rejecting requests will usually mean generating appropriate Diameter error responses. For a Diameter client, rejecting requests will depend upon the application. For example, it could mean giving an indication to the entity requesting the Diameter service that the network is busy and to try again later. Stateless applications: By definition there is no relationship between individual requests in a stateless application. As a result, when a request is sent or relayed to an overloaded Diameter entity - either a Diameter Server or a Diameter Agent - the sending or relaying entity can choose to apply the overload treatment to any request targeted for the overloaded entity. Pseudo-session applications: Korhonen, et al. Expires April 24, 2015 [Page 35] Internet-Draft DOIC October 2014 For pseudo-session applications, there is an implied ordering of requests. As a result, decisions about which requests towards an overloaded entity to reject could take the command code of the request into consideration. This generally means that transactions later in the sequence of transactions should be given more favorable treatment than messages earlier in the sequence. This is because more work has already been done by the Diameter network for those transactions that occur later in the sequence. Rejecting them could result in increasing the load on the network as the transactions earlier in the sequence might also need to be repeated. Session-based applications: Overload handling for session-based applications must take into consideration the work load associated with setting up and maintaining a session. As such, the entity sending requests towards an overloaded Diameter entity for a session-based application might tend to reject new session requests prior to rejecting intra-session requests. In addition, session ending requests might be given a lower probability of being rejected as rejecting session ending requests could result in session status being out of sync between the Diameter clients and servers. Application designers that would decide to reject mid-session requests will need to consider whether the rejection invalidates the session and any resulting session clean-up procedures. C.3. Request Transaction Classification Independent Request: An independent request is not correlated to any other requests and, as such, the lifetime of the session-id is constrained to an individual transaction. Session-Initiating Request: A session-initiating request is the initial message that establishes a Diameter session. The ACR message defined in [RFC6733] is an example of a session-initiating request. Correlated Session-Initiating Request: There are cases when multiple session-initiated requests must be correlated and managed by the same Diameter server. It is notably the case in the 3GPP PCC architecture [PCC], where multiple apparently independent Diameter application sessions are actually correlated and must be handled by the same Diameter server. Korhonen, et al. Expires April 24, 2015 [Page 36] Internet-Draft DOIC October 2014 Intra-Session Request: An intra session request is a request that uses the same Session- Id than the one used in a previous request. An intra session request generally needs to be delivered to the server that handled the session creating request for the session. The STR message defined in [RFC6733] is an example of an intra-session requests. Pseudo-Session Requests: Pseudo-session requests are independent requests and do not use the same Session-Id but are correlated by other session-related information contained in the request. There exists Diameter applications that define an expected ordering of transactions. This sequencing of independent transactions results in a pseudo session. The AIR, MAR and SAR requests in the 3GPP defined Cx [Cx] application are examples of pseudo-session requests. C.4. Request Type Overload Implications The request classes identified in Appendix C.3 have implications on decisions about which requests should be throttled first. The following list of request treatment regarding throttling is provided as guidelines for application designers when implementing the Diameter overload control mechanism described in this document. The exact behavior regarding throttling is a matter of local policy, unless specifically defined for the application. Independent requests: Independent requests can generally be given equal treatment when making throttling decisions, unless otherwise indicated by application requirements or local policy. Session-initiating requests: Session-initiating requests often represent more work than independent or intra-session requests. Moreover, session- initiating requests are typically followed by other session- related requests. Since the main objective of the overload control is to reduce the total number of requests sent to the overloaded entity, throttling decisions might favor allowing intra-session requests over session-initiating requests. In the absence of local policies or application specific requirements to the contrary, Individual session-initiating requests can be given equal treatment when making throttling decisions. Correlated session-initiating requests: Korhonen, et al. Expires April 24, 2015 [Page 37] Internet-Draft DOIC October 2014 A Request that results in a new binding, where the binding is used for routing of subsequent session-initiating requests to the same server, represents more work load than other requests. As such, these requests might be throttled more frequently than other request types. Pseudo-session requests: Throttling decisions for pseudo-session requests can take into consideration where individual requests fit into the overall sequence of requests within the pseudo session. Requests that are earlier in the sequence might be throttled more aggressively than requests that occur later in the sequence. Intra-session requests: There are two classes of intra-sessions requests. The first class consists of requests that terminate a session. The second class comprises requests that are used by the Diameter client and server to maintain the ongoing session state. Implementors and operators may choose to throttle session-terminating requests less aggressively in order to gracefully terminate sessions, allow clean-up of the related resources (e.g. session state) and avoid the need for additional intra-session requests. Favoring session- termination requests may reduce the session management impact on the overloaded entity. The default handling of other intra- session requests might be to treat them equally when making throttling decisions. There might also be application level considerations whether some request types are favored over others. Authors' Addresses Jouni Korhonen (editor) Broadcom Porkkalankatu 24 Helsinki FIN-00180 Finland Email: jouni.nospam@gmail.com Steve Donovan (editor) Oracle 7460 Warren Parkway Frisco, Texas 75034 United States Email: srdonovan@usdonovans.com Korhonen, et al. Expires April 24, 2015 [Page 38] Internet-Draft DOIC October 2014 Ben Campbell Oracle 7460 Warren Parkway Frisco, Texas 75034 United States Email: ben@nostrum.com Lionel Morand Orange Labs 38/40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France Phone: +33145296257 Email: lionel.morand@orange.com Korhonen, et al. Expires April 24, 2015 [Page 39] --------------030209050001040106090500-- From nobody Tue Oct 21 22:49:06 2014 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 5BABB1A8AB1 for ; Tue, 21 Oct 2014 22:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 v6IfQUIpfwXS for ; Tue, 21 Oct 2014 22:11:41 -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 65C271A8AAD for ; Tue, 21 Oct 2014 22:11:41 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:53937 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgoCw-0000pT-D8 for dime@ietf.org; Tue, 21 Oct 2014 22:11:39 -0700 Message-ID: <54473C8A.5030801@usdonovans.com> Date: Wed, 22 Oct 2014 07:11:38 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------000300020505070805010105" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/refnqRWm7msDz3st3BGE1ezqB5o X-Mailman-Approved-At: Tue, 21 Oct 2014 22:49:05 -0700 Subject: [Dime] Resolution to issue 69 and part of issue 23 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, 22 Oct 2014 05:11:48 -0000 This is a multi-part message in MIME format. --------------000300020505070805010105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I added Lionel's proposed wording to the reporting node sub section of the overload report handling section. I also modified the first paragraph below and added the other two paragraphs. Those changes were not directly related to issue 69 but were needed in this section. The reporting node MAY update the overload report with new reduction percentages. The reacting node MAY extend the validatity duration for an existing overload report by sending a OLR with either the same or a new validity duration value. When doing so, the reacting node MUST increase the sequence number in the new OLR sent. When sending an overload report with new values in any of the sub AVPs for an existing overload condition, the reporting node MUST increase the sequence number in the new OLR sent. I have attached the diff file. Regards, Steve --------------000300020505070805010105 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 2, line 34 skipping to change at page 2, line 34
4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12
4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12
4.2. Overload Report Processing . . . . . . . . . . . . . . . 13 4.2. Overload Report Processing . . . . . . . . . . . . . . . 13
4.2.1. Overload Control State . . . . . . . . . . . . . . . 13 4.2.1. Overload Control State . . . . . . . . . . . . . . . 13
4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16
4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17
4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 19 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 19
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 21 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 21
5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 22 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 23 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 22
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 23 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 24 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 24
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 25 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 26
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 29 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 30 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 30
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 31 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 30
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Issues left for future specifications . . . . . . . 33 Appendix A. Issues left for future specifications . . . . . . . 32
A.1. Additional traffic abatement algorithms . . . . . . . . . 33 A.1. Additional traffic abatement algorithms . . . . . . . . . 33
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 33 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 33
A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 33 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 33
Appendix B. Deployment Considerations . . . . . . . . . . . . . 33 Appendix B. Deployment Considerations . . . . . . . . . . . . . 33
Appendix C. Considerations for Applications Integrating the DOIC Appendix C. Considerations for Applications Integrating the DOIC
Solution . . . . . . . . . . . . . . . . . . . . . . 34 Solution . . . . . . . . . . . . . . . . . . . . . . 34
C.1. Application Classification . . . . . . . . . . . . . . . 34 C.1. Application Classification . . . . . . . . . . . . . . . 34
C.2. Application Type Overload Implications . . . . . . . . . 35 C.2. Application Type Overload Implications . . . . . . . . . 35
C.3. Request Transaction Classification . . . . . . . . . . . 36 C.3. Request Transaction Classification . . . . . . . . . . . 36
C.4. Request Type Overload Implications . . . . . . . . . . . 37 C.4. Request Type Overload Implications . . . . . . . . . . . 37
skipping to change at page 18, line 34 skipping to change at page 18, line 34
Note that a reacting node advertises support for the host and Note that a reacting node advertises support for the host and
realm report types by including the OC-Supported-Features AVP in realm report types by including the OC-Supported-Features AVP in
the request. Support for other report types must be explicitly the request. Support for other report types must be explicitly
indicated by a new feature bit in the OC-Feature-Vector AVP. indicated by a new feature bit in the OC-Feature-Vector AVP.
If OLR is for a new overload condition and there is no unexpired If OLR is for a new overload condition and there is no unexpired
overload report for previous overload conditions at any reacting node overload report for previous overload conditions at any reacting node
then the reporting node MAY set the sequence number to any value. then the reporting node MAY set the sequence number to any value.
The reporting node MAY update the overload report with new reduction The reacting node MAY update the overload report with new reduction
percentages. percentages. When doing so, the reacting node MUST increase the
sequence number in the new OLR sent.
The reporting node MAY extend the validatity duration for an existing
overload report by sending a OLR with either the same or a new
validity duration value.
When sending an overload report with new values in any of the sub
AVPs for an existing overload condition, the reporting node MUST
increase the sequence number in the new OLR sent.
When generating sequence numbers for new overload conditions, the new When generating sequence numbers for new overload conditions, the new
sequence number MUST be greater than any sequence number in an active sequence number MUST be greater than any sequence number in an active
(unexpired) overload report previously sent by the reporting node. (unexpired) overload report previously sent by the reporting node.
This property MUST hold over a reboot of the reporting node. This property MUST hold over a reboot of the reporting node.
A reporting node MAY rely on the OC-Validity-Duration AVP values for A reporting node MAY rely on the OC-Validity-Duration AVP values for
the implicit overload control state cleanup on the reacting node. the implicit overload control state cleanup on the reacting node.
However, it is RECOMMENDED that the reporting node always explicitly However, it is RECOMMENDED that the reporting node always explicitly
indicates the end of a overload condition. indicates the end of a overload condition.
The reporting node SHOULD indicate the end of an overload occurrence The reporting node SHOULD indicate the end of an overload occurrence
by sending a new OLR with OC-Validity-Duration set to a value of zero by sending a new OLR with OC-Validity-Duration set to a value of zero
("0"). The reporting node SHOULD insure that all reacting nodes ("0"). The reporting node SHOULD insure that all reacting nodes
receive the updated overload report. receive the updated overload report.
When a reporting node sends an OLR, it effectively delegates any
necessary throttling to downstream nodes. Therefore, the reporting
node SHOULD NOT apply throttling to the set of messages to which the
OLR applies. That is, the same candidate set of messages SHOULD NOT
be throttled multiple times.
However, when the reporting node sends and OLR downstream, it MAY
still be responsible to apply other abatement methods, such as
diversion, or request throttling requests for other reasons. For
example, an agent or server might have a configured rate limit for
each client, and throttle requests that exceed that limit, even if
such requests had already been candidates for throttling by
downstream nodes.
All OLRs sent have an expiration time calculated by adding the All OLRs sent have an expiration time calculated by adding the
validity-duration contained in the OLR to the time the message was validity-duration contained in the OLR to the time the message was
sent. Transit time for the OLR can be safely ignored. The sent. Transit time for the OLR can be safely ignored. The
reporting node can ensure that all reacting nodes have received reporting node can ensure that all reacting nodes have received
the OLR by continuing to send it in answer messages until the the OLR by continuing to send it in answer messages until the
expiration time for all OLRs sent for that overload contition have expiration time for all OLRs sent for that overload contition have
expired. expired.
This document assumes that there is a single source for realm-reports This document assumes that there is a single source for realm-reports
for a given realm, or that if multiple nodes can send realm reports, for a given realm, or that if multiple nodes can send realm reports,
 End of changes. 12 change blocks. 
36 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------000300020505070805010105-- From nobody Tue Oct 21 23:33:23 2014 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 0B3861A6F85 for ; Tue, 21 Oct 2014 23:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 u9b0dBnIjDht for ; Tue, 21 Oct 2014 23:33: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 E9E721A01EC for ; Tue, 21 Oct 2014 23:33:18 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:54142 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgpTu-0006AZ-Cw; Tue, 21 Oct 2014 23:33:16 -0700 Message-ID: <54474FA9.3040300@usdonovans.com> Date: Wed, 22 Oct 2014 08:33:13 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell References: <5444E8B9.8090002@usdonovans.com> <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> <22114_1413841265_54458171_22114_4224_1_6B7134B31289DC4FAF731D844122B36E8005B4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, <>> <1979_1413867197_5445E6BD_1979_10335_1_s8e3rg7h7yyc2r23mds3uefp.1413867190363@email.android.com> <5446190F.2070804@usdonovans.com> <99D5FF0E-2D2B-4DB1-8C9C-19296A8D1822@nostrum.com> In-Reply-To: <99D5FF0E-2D2B-4DB1-8C9C-19296A8D1822@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/X87GgMdPVGctBDqcm1aQCl6eYWg Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for error response wording (issue 85) 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, 22 Oct 2014 06:33:21 -0000 Ben, I missed the other comment. The MUST wording you suggest will be in the next revision of the -04 draft. Yes on your question about the SHOULD. Do you think we need wording saying that implementations can make other choices if they have good reason? Steve On 10/21/14, 4:46 PM, Ben Campbell wrote: > Did we intend to include anything about Lionel's suggestion on UNABLE_TO_DELIVER? (I am neutral on that--I just wanted to make sure we didn't forget to consider it.) > > I also have one comment inline. Otherwise it looks good to me. > > >> On Oct 21, 2014, at 3:27 AM, Steve Donovan wrote: >> >> I have incorporated the following text into the document in the existing, previously empty, section 7. Error Response Codes. >> >> I will wait until tomorrow to close issue 85 to allow for discussion of the proposed wording. >> >> I have attached the diff as this wording is not in the draft. >> >> Regards, >> >> Steve >> >> --- >> >> When a DOIC node rejects a Diameter request due to throttling, the >> DOIC node needs to select the appropriate error response code. > Do we have separate text saying the node MUST send an error? If not, I suggest changing this to "... MUST respond with an appropriate error response code." > > The change from "the" to "an" was intentional. Since we are using SHOULD below for the actual choice, I assume we intend to leave room for an implementation to make other choices if it has a good reason. > > >> This >> determination is made based on the probability of the request >> succeeding if retried on a different path. >> >> The DIAMETER_TOO_BUSY response code SHOULD be used when the request >> is likely to succeed on a different path. >> >> For instance, if the request arrived at the reporting node without >> a Destination-Host AVP then the reporting node might determine >> that there is an alternative Diameter node that could successfully >> process the request and that retrying the transaction would not >> negatively impact the reporting node. >> >> The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to >> indicate that the request should not be retried. This is used when >> the request is not likely to succeed on a different path and retrying >> would consume valuable resources during an occurance of overload. >> >> For instance, if the request arrived at the reporting node with a >> Destination-Host AVP populated with its own Diameter identity then >> the reporting node can assume that retrying the request would >> result in it coming to the same reporting node. >> >> A second example is when an agent that supports the DOIC solution >> is preforming the role of a reacting node for a non supporting >> client. Requests that are rejected as a result of DOIC throttling >> in this scenario would generally be rejected with a >> DIAMETER_UNABLE_TO_COMPLY response code. >> >> >> >> >> On 10/21/14, 6:53 AM, lionel.morand@orange.com wrote: >>> I agree. >>> >>> Lionel >>> >>> Envoyé depuis mon Sony Xperia SP d'Orange >>> >>> ---- Ben Campbell a écrit ---- >>> >>> >>> >>>> On Oct 20, 2014, at 4:41 PM, >>>> wrote: >>>> >>>> Hi, >>>> >>>> I think that: >>>> - TOO_BUSY should be restricted to server answer >>>> >>> One of the reasons I think we need to state this by intended result and not by role in the network, is that I expect that an overloaded agent (according to the agent overload draft) might send TOO-BUSY. And a server that acts as an overload authority for a realm might send UNABLE-TO-[COMPLY or DELIVER] to a request that did not contain a Destination-Host AVP. >>> >>> >>>> - UNABLE_TO_COMPLY as answer to non-supporting DOIC when no retransmission is required >>>> - UNABLE_TO_DELIVER to supporting DOIC and to non-supporting DOIC node when retransmission to an alternate peer could be better. >>>> >>>> As a second step, we could enhance the answer message (in this draft or in a separate draft if preferred) with an error message (e.g. "Error-Diagnostic") that could provide further information to "new" node that will be then able to adapt their behavior. >>>> So a supporting DOIC receiving UNABLE_TO_DELIVER/TOO_BUSY with an Error-Diagnostic set to e.g. "severe overload", besides the OLR in the answer, will know that retransmission on the path or a on a different path will likely cause the same error. If no error-diagnostic is sent back or ignored by the non-supporting-DOOIC node, we will go back to the situation prior this draft. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> -----Message d'origine----- >>>> De : DiME [ >>>> mailto:dime-bounces@ietf.org >>>> ] De la part de Ben Campbell >>>> Envoyé : lundi 20 octobre 2014 19:10 >>>> À : Steve Donovan >>>> Cc : >>>> dime@ietf.org >>>> >>>> Objet : Re: [Dime] Proposal for error response wording (issue 85) >>>> >>>> I agree that we should generalize these, but I think the direction is not quite right. More inline: >>>> >>>> >>>>> On Oct 20, 2014, at 5:49 AM, Steve Donovan >>>>> wrote: >>>>> >>>>> We came to the following agreements on error responses: >>>>> >>>>> - Servers rejecting a Diameter request due to an overload condition should send a 3002 DIAMETER_TOO_BUSY error response. >>>>> >>>>> - Agents rejecting a Diameter request due to an overload condition should send a 5012 DIAMETER_UNABLE_TO_COMPLY. >>>>> >>>>> I propose that we generalize this to the following: >>>>> >>>>> - Reporting nodes rejecting a Diameter request due to an overload condition SHOULD send a 3002 DIAMETER-TOO-BUSY error response. >>>>> >>>>> - Reacting nodes rejecting a Diameter request due to an overload condition SHOULD send a UNABLE-TO-COMPLY. >>>>> >>>> I don't think we should state this in terms of reaction and reporting nodes. I think we should generalize to expected behavior. Also, in the case where the downstream node does not support DOIC, I'm not sure it makes sense to say the throttling node is really a reporting node (for that particular relationship.) >>>> >>>> My suggestion is we say that, if the throttling node has sufficient information to determine that the request is not likely to succeed if retried on another path, it SHOULD send UNABLE-TO-COMPLY. If it does not have that information, it SHOULD send TOO-BUSY. (we should discuss why this is not a MUST if we have the conditionals in place.) >>>> >>>> Then we could go on to say that a reaction node (or agent) would typically fall under the first category, and a reporting node (or server) would typically fall under the second. But there certainly may be cases where a reacting node does not know if other paths could work, and where a reporting node might know that they couldn't. >>>> >>>> >>>> >>>>> This would mean that an agent acting as a reporting node (i.e.; server doesn't support DOIC or agent is acting as a server front end) would sent the TOO_BUSY response and an agent acting as a reacting node (i.e.; a client doesn't support DOIC) then it sends a UNABLE_TO_COMPLY response. >>>>> >>>>> I propose adding this to a new section 4.2.4. The existing 4.2.4 on agent behavior will be deleted. >>>>> >>>>> I will hold off making this change until tomorrow (Tuesday morning). >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> >>>>> _______________________________________________ >>>>> 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. >>> >>> >>> >> > From nobody Tue Oct 21 23:35:26 2014 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 BA9501A897B for ; Tue, 21 Oct 2014 23:35:23 -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 xMY2Jd6GS-op for ; Tue, 21 Oct 2014 23:35:20 -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 ADF7C1A6F9D for ; Tue, 21 Oct 2014 23:35:20 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:54143 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgpVr-0007WS-GH for dime@ietf.org; Tue, 21 Oct 2014 23:35:18 -0700 Message-ID: <54474FFF.50809@usdonovans.com> Date: Wed, 22 Oct 2014 08:34:39 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030202050209080002020508" 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/B-u2M-x55qM0N93b7gdQcc69YtI Subject: Re: [Dime] Resolution of issue #73 clarifications on M-bit 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, 22 Oct 2014 06:35:23 -0000 This is a multi-part message in MIME format. --------------030202050209080002020508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jean-Jacques, I have made changes and closed issue #73. Please look at the version of the draft I sent this morning and see if the changes I made for this issue are acceptable. If not, please let me know and I'll update accordingly. Regards, Steve On 10/21/14, 11:25 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: > > Dear all > > In reference to the Lionel's minutes on issue #73 Clarifications on > the M-bit: > > Summary: Mbit is mentioned in different places in the 03 draft > (sections 4.3, 6 and 6.8). It is proposed clarifications to ensure a > good consistency between the different sections. > > Output of the discussion: > > It is agreed that the draft should just refer to the RFC6733 for > everything regarding the M-bit setting. How and when to set the M-bit > is defined in the base protocol. > > I will follow the output of the discussion, taking into account that I > think we still need to indicate that for existing applications, the > Mbit should be cleared for backward compatibility. > > Hereafter the different places where M-bit is mentioned with the > proposed changes > > In 4.3. Protocol Extensibility > > Existing text: > > It should be noted that [RFC6733] defined Grouped AVP extension > > mechanisms apply. This allows, for example, defining a new feature > > that is mandatory to be understood even when piggybacked on an > > existing applications. More specifically, the sub-AVPs inside the > > OC-Supported-Features and OC-OLR AVP MAY have the M-bit set. > > However, when overload control AVPs are piggybacked on top of an > > existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED. > > Proposal: To keep the reference to RFC 6733; the text about existing > applications is removed as overlapping with the 6.8 one. > > It should be noted that [RFC6733] defined Grouped AVP extension > > mechanisms apply. > > In 6. Attribute Value Pairs > > Existing text > > This section describes the encoding and semantics of the Diameter > > Overload Indication Attribute Value Pairs (AVPs) defined in this > > document. > > When added to existing commands, both OC-Feature-Vector and OC-OLR > > AVPs SHOULD have the M-bit flag cleared to avoid backward > > compatibility issues. > > A new application specification can incorporate the overload control > > mechanism specified in this document by making it mandatory to > > implement for the application and referencing this specification > > normatively. In such a case, the OC-Feature-Vector and OC-OLR AVPs > > reused in newly defined Diameter applications SHOULD have the M-bit > > flag set. However, it is the responsibility of the Diameter > > application designers to define how overload control mechanisms works > > on that application. > > Proposal: to remove two paragraphs as overlapping with 6.8** > > This section describes the encoding and semantics of the Diameter > > Overload Indication Attribute Value Pairs (AVPs) defined in this > > document. > > In 6.8. Attribute Value Pair flag rules > > Existing text > > As described in the Diameter base protocol [RFC6733], the M-bit > > setting for a given AVP is relevant to an application and each > > command within that application that includes the AVP. > > The Diameter overload control AVPs SHOULD always be sent with the > > M-bit cleared when used within existing Diameter applications to > > avoid backward compatibility issues. Otherwise, when reused in newly > > defined Diameter applications, the DOC related AVPs SHOULD have the > > M-bit set. > > Proposal:**To keep the reference to RFC 6733 and the particular case > of existing applications > > ** > > As described in the Diameter base protocol [RFC6733], the M-bit > > setting for a given AVP is relevant to an application and each > > command within that application that includes the AVP. However, the > > Diameter overload control AVPs SHOULD always be sent with the > > M-bit cleared when used within existing Diameter applications to > > avoid backward compatibility issues. > > If OK, I will update the proposal for the issue #73 in the Dime Tracker > > Best regards > > JJacques > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------030202050209080002020508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jean-Jacques,

I have made changes and closed issue #73.

Please look at the version of the draft I sent this morning and see if the changes I made for this issue are acceptable.  If not, please let me know and I'll update accordingly.

Regards,

Steve

On 10/21/14, 11:25 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:

Dear all

 

In reference to the Lionel’s minutes on  issue #73 Clarifications on the M-bit:

Summary: Mbit is mentioned in different places in the 03 draft (sections 4.3, 6 and 6.8). It is proposed clarifications to ensure a good consistency between the different sections.

 

Output of the discussion:

It is agreed that the draft should just refer to the RFC6733 for everything regarding the M-bit setting. How and when to set the M-bit is defined in the base protocol.

 

I will follow the output of the discussion, taking into account that I think we still need to indicate that for existing applications, the Mbit should be cleared for backward compatibility.

 

Hereafter the different places where M-bit is mentioned with the proposed changes

 

In 4.3.  Protocol Extensibility

 

Existing text:

   It should be noted that [RFC6733] defined Grouped AVP extension

   mechanisms apply.  This allows, for example, defining a new feature

   that is mandatory to be understood even when piggybacked on an

   existing applications.  More specifically, the sub-AVPs inside the

   OC-Supported-Features and OC-OLR AVP MAY have the M-bit set.

   However, when overload control AVPs are piggybacked on top of an

   existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED.

 

Proposal: To keep the reference to RFC 6733;  the text about  existing applications is removed as  overlapping with the 6.8 one.

 

   It should be noted that [RFC6733] defined Grouped AVP extension

   mechanisms apply.

 

 

In 6.  Attribute Value Pairs

 

Existing text

   This section describes the encoding and semantics of the Diameter

   Overload Indication Attribute Value Pairs (AVPs) defined in this

   document.

 

   When added to existing commands, both OC-Feature-Vector and OC-OLR

   AVPs SHOULD have the M-bit flag cleared to avoid backward

   compatibility issues.

 

   A new application specification can incorporate the overload control

   mechanism specified in this document by making it mandatory to

   implement for the application and referencing this specification

   normatively.  In such a case, the OC-Feature-Vector and OC-OLR AVPs

   reused in newly defined Diameter applications SHOULD have the M-bit

   flag set.  However, it is the responsibility of the Diameter

   application designers to define how overload control mechanisms works

   on that application.

 

 

Proposal: to remove two paragraphs as overlapping with 6.8

   This section describes the encoding and semantics of the Diameter

   Overload Indication Attribute Value Pairs (AVPs) defined in this

   document.

 

 

In 6.8.  Attribute Value Pair flag rules

 

Existing text

   As described in the Diameter base protocol [RFC6733], the M-bit

   setting for a given AVP is relevant to an application and each

   command within that application that includes the AVP.

 

   The Diameter overload control AVPs SHOULD always be sent with the

   M-bit cleared when used within existing Diameter applications to

   avoid backward compatibility issues.  Otherwise, when reused in newly

   defined Diameter applications, the DOC related AVPs SHOULD have the

   M-bit set.

 

Proposal: To keep the reference to RFC 6733 and the particular case of existing applications

 

   As described in the Diameter base protocol [RFC6733], the M-bit

   setting for a given AVP is relevant to an application and each

   command within that application that includes the AVP. However, the

   Diameter overload control AVPs SHOULD always be sent with the

   M-bit cleared when used within existing Diameter applications to

   avoid backward compatibility issues.

 

If OK, I will update the proposal for the issue #73 in the Dime Tracker

 

Best regards

 

JJacques 



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

--------------030202050209080002020508-- From nobody Tue Oct 21 23:55:06 2014 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 91A501A6F85 for ; Tue, 21 Oct 2014 23:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HJepfBlgKENW for ; Tue, 21 Oct 2014 23:55:04 -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 898AC1A1A90 for ; Tue, 21 Oct 2014 23:55:04 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:54264 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xgpoz-0007xN-FB; Tue, 21 Oct 2014 23:55:02 -0700 Message-ID: <544754C5.7070809@usdonovans.com> Date: Wed, 22 Oct 2014 08:55:01 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell References: <5444D8F9.9040906@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/we2PrWEObp20HFj2BK5dhJabYzc Cc: "dime@ietf.org" Subject: Re: [Dime] Resolution to issues 70 and 74 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, 22 Oct 2014 06:55:05 -0000 The other way of wording this would be as follows: A reporting node MUST NOT send overload reports of a type that has not been advertized as supported by the reacting node. Which is an explicit double negation that is necessary to get the point across. The above wording will be in the next revision of the draft. I'm open to other wording if someone has a cleaner way of getting this requirement across. Regards, Steve On 10/20/14, 11:17 PM, Ben Campbell wrote: > Slight normative language quibble: > > "MUST only" is a bit of a strange construction from a 2119 perspective, in that it implies a negation without an explicit NOT. I think we really mean "MUST NOT unless...". > > >> On Oct 20, 2014, at 4:42 AM, Steve Donovan wrote: >> >> I have removed the examples section and moved the "Application Considerations" section to an appendix. >> >> For issue 70 I also added the following wording to section 4.2.3: >> >> A reporting node MUST only send overload reports of a type advertised >> as supported by the reacting node. >> >> Note that a reacting node advertises support for the host and >> realm report types by including the OC-Supported-Features AVP in >> the request. Support for other report types must be explicitly >> indicated by a new feature bit in the OC-Feature-Vector AVP. >> >> >> >> The diff file is attached. >> >> Regards, >> >> Steve >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Oct 22 01:03:42 2014 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 4AA781A8AE5 for ; Wed, 22 Oct 2014 01:03:39 -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, HTML_MESSAGE=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 BUY3EtdwsCCp for ; Wed, 22 Oct 2014 01:03:30 -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 3FC421A8AF8 for ; Wed, 22 Oct 2014 01:03:29 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id B8AF498E7FEB0; Wed, 22 Oct 2014 08:03:23 +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 s9M83GX6000590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 10:03:25 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.50]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 10:03:21 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Resolution of issue #73 clarifications on M-bit Thread-Index: AQHP7cJkLolqcTksaUanLWryhCNWDZw7vAkw Date: Wed, 22 Oct 2014 08:03:21 +0000 Message-ID: References: <54474FFF.50809@usdonovans.com> In-Reply-To: <54474FFF.50809@usdonovans.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_E194C2E18676714DACA9C3A2516265D2026E8C54FR712WXCHMBA12z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/RnYf7EiDBJ1JHe-NvgMEzWWt2mw Subject: Re: [Dime] Resolution of issue #73 clarifications on M-bit 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, 22 Oct 2014 08:03:39 -0000 --_000_E194C2E18676714DACA9C3A2516265D2026E8C54FR712WXCHMBA12z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Steve Comments on your changes For 4.3 Protocol Extensibility, I am OK For 6. Attribute Value Pairs, I considered the existing text of 2 paragrap= hs was overlapping with the one in 6.8. When we duplicate text but with wording differences, it may rise ambiguiti= es with the questioning of why the text is different. So I prefer to have one place to deal with M-bit and 6.8 seems for me the r= ight place as dealing with AVP flag rules (so covering M-bit), and we do no= t need to say something in 6. In 6.8, my proposal is to remove " Otherwise, when reused in newly defined Diameter applications, the DOC related AVPs SHOULD have the M-bit set." This point was discussed and it depends on how the application deals with D= iameter overaload. if it is optional the MBit is not set . So here as acco= rding to the output discussion, only the reference to RFC 6733 is sufficien= t (1st paragraph). We nevertheless keep the statement for existing applicat= ions. Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : mercredi 22 octobre 2014 08:35 =C0 : dime@ietf.org Objet : Re: [Dime] Resolution of issue #73 clarifications on M-bit Jean-Jacques, I have made changes and closed issue #73. Please look at the version of the draft I sent this morning and see if the = changes I made for this issue are acceptable. If not, please let me know a= nd I'll update accordingly. Regards, Steve On 10/21/14, 11:25 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: Dear all In reference to the Lionel's minutes on issue #73 Clarifications on the M-= bit: Summary: Mbit is mentioned in different places in the 03 draft (sections 4.= 3, 6 and 6.8). It is proposed clarifications to ensure a good consistency b= etween the different sections. Output of the discussion: It is agreed that the draft should just refer to the RFC6733 for everything= regarding the M-bit setting. How and when to set the M-bit is defined in t= he base protocol. I will follow the output of the discussion, taking into account that I thin= k we still need to indicate that for existing applications, the Mbit should= be cleared for backward compatibility. Hereafter the different places where M-bit is mentioned with the proposed c= hanges In 4.3. Protocol Extensibility Existing text: It should be noted that [RFC6733] defined Grouped AVP extension mechanisms apply. This allows, for example, defining a new feature that is mandatory to be understood even when piggybacked on an existing applications. More specifically, the sub-AVPs inside the OC-Supported-Features and OC-OLR AVP MAY have the M-bit set. However, when overload control AVPs are piggybacked on top of an existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED. Proposal: To keep the reference to RFC 6733; the text about existing appl= ications is removed as overlapping with the 6.8 one. It should be noted that [RFC6733] defined Grouped AVP extension mechanisms apply. In 6. Attribute Value Pairs Existing text This section describes the encoding and semantics of the Diameter Overload Indication Attribute Value Pairs (AVPs) defined in this document. When added to existing commands, both OC-Feature-Vector and OC-OLR AVPs SHOULD have the M-bit flag cleared to avoid backward compatibility issues. A new application specification can incorporate the overload control mechanism specified in this document by making it mandatory to implement for the application and referencing this specification normatively. In such a case, the OC-Feature-Vector and OC-OLR AVPs reused in newly defined Diameter applications SHOULD have the M-bit flag set. However, it is the responsibility of the Diameter application designers to define how overload control mechanisms works on that application. Proposal: to remove two paragraphs as overlapping with 6.8 This section describes the encoding and semantics of the Diameter Overload Indication Attribute Value Pairs (AVPs) defined in this document. In 6.8. Attribute Value Pair flag rules Existing text As described in the Diameter base protocol [RFC6733], the M-bit setting for a given AVP is relevant to an application and each command within that application that includes the AVP. The Diameter overload control AVPs SHOULD always be sent with the M-bit cleared when used within existing Diameter applications to avoid backward compatibility issues. Otherwise, when reused in newly defined Diameter applications, the DOC related AVPs SHOULD have the M-bit set. Proposal: To keep the reference to RFC 6733 and the particular case of exis= ting applications As described in the Diameter base protocol [RFC6733], the M-bit setting for a given AVP is relevant to an application and each command within that application that includes the AVP. However, the Diameter overload control AVPs SHOULD always be sent with the M-bit cleared when used within existing Diameter applications to avoid backward compatibility issues. If OK, I will update the proposal for the issue #73 in the Dime Tracker Best regards JJacques _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E194C2E18676714DACA9C3A2516265D2026E8C54FR712WXCHMBA12z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Steve

 

Comments  on your= changes

 

For 4.3 Protoco= l Extensibility, I am OK

 

For 6.  At= tribute Value Pairs, I considered the existing text of 2 paragraphs was ove= rlapping with the one in 6.8.  

When we duplicate text but with  wording differ= ences, it may rise ambiguities with the questioning of why the text is diff= erent.

 

So I prefer to have one place to deal with M-bit and= 6.8 seems for me the right place as dealing with AVP flag rules (so coveri= ng M-bit), and we do not need to say something in 6.

 

In 6.8, my proposal is to remove

   “ Otherwise, when reused in = newly

   defined Diameter applications, the DOC = related AVPs SHOULD have the

   M-bit set.”

 

This point was discussed and it depends on how the a= pplication deals with Diameter overaload. if it is optional the MBit is not= set . So here  as according to the output discussion, only the refere= nce to RFC 6733 is sufficient (1st paragraph). We nevertheless keep the statement for existing applications.<= o:p>

 

Best regards

 

JJacques

 

De := DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 22 octobre 2014 08:35
=C0 : dime@ietf.org
Objet :<= span lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma",&= quot;sans-serif";color:windowtext"> Re: [Dime] Resolution of issue #73= clarifications on M-bit

 

Jean-Jacques,

I have made changes and closed issue #73.

Please look at the version of the draft I sent this morning and see if the = changes I made for this issue are acceptable.  If not, please let me k= now and I'll update accordingly.

Regards,

Steve

On 10/21/14, 11:25 PM, TROTTIN, JEAN-JACQUES (JEAN-J= ACQUES) wrote:

Dear all

 

In reference to the Lionel’s minutes on  = issue #73 Clarifications on the M-bit:

Summary: Mbit is men= tioned in different places in the 03 draft (sections 4.3, 6 and 6.8). It is= proposed clarifications to ensure a good consistency between the different= sections.

 

Output of the discus= sion:

It is agreed that th= e draft should just refer to the RFC6733 for everything regarding the M-bit= setting. How and when to set the M-bit is defined in the base protocol.

 

I will follow the output of the discussion, taking i= nto account that I think we still need to indicate that for existing applic= ations, the Mbit should be cleared for backward compatibility.

 

Hereafter the different places where M-bit is mentio= ned with the proposed changes

 

In 4.3.  Protocol Extensibility

 

Existing text:

   It should be noted that [RFC6733] define= d Grouped AVP extension

   mechanisms apply.  This allows, for exam= ple, defining a new feature

   that is mandatory to be understood even when = piggybacked on an

   existing applications.  More specificall= y, the sub-AVPs inside the

   OC-Supported-Features and OC-OLR AVP MAY have= the M-bit set.

   However, when overload control AVPs are piggy= backed on top of an

   existing applications, setting M-bit in sub-A= VPs is NOT RECOMMENDED.

 

Proposal: To keep the reference to RFC 6733;  t= he text about  existing applications is removed as  overlapping w= ith the 6.8 one.

 

   It should be noted that [RFC6733] defined Gro= uped AVP extension

   mechanisms apply.

 

 

In 6.  Attribute Value Pairs

 

Existing text

   This section describes the encoding and seman= tics of the Diameter

   Overload Indication Attribute Value Pairs (AV= Ps) defined in this

   document.

 

   When added to existing commands, both OC-Feat= ure-Vector and OC-OLR

   AVPs SHOULD have the M-bit flag cleared to av= oid backward

   compatibility issues.

 

   A new application specification can incorpora= te the overload control

   mechanism specified in this document by makin= g it mandatory to

   implement for the application and referencing= this specification

   normatively.  In such a case, the OC-Fea= ture-Vector and OC-OLR AVPs

   reused in newly defined Diameter applications= SHOULD have the M-bit

   flag set.  However, it is the responsibi= lity of the Diameter

   application designers to define how overload = control mechanisms works

   on that application.

 

 

Proposal: to remove two paragraphs as overlapping wi= th 6.8

   This section describes the encoding and = semantics of the Diameter

   Overload Indication Attribute Value Pairs (AV= Ps) defined in this

   document.

 

 

In 6.8.  Attribute Value Pair flag rules

 

Existing text

   As described in the Diameter base protocol [R= FC6733], the M-bit

   setting for a given AVP is relevant to an app= lication and each

   command within that application that includes= the AVP.

 

   The Diameter overload control AVPs SHOULD alw= ays be sent with the

   M-bit cleared when used within existing Diame= ter applications to

   avoid backward compatibility issues.  Ot= herwise, when reused in newly

   defined Diameter applications, the DOC relate= d AVPs SHOULD have the

   M-bit set.

 

Proposal: To keep the reference to RFC 6733 and the particular case of existing = applications

 

   As described in the Diameter base protocol [R= FC6733], the M-bit

   setting for a given AVP is relevant to an app= lication and each

   command within that application that includes= the AVP. However, the

   Diameter overload control AVPs SHOULD always = be sent with the

   M-bit cleared when used within existing Diame= ter applications to

   avoid backward compatibility issues.

 

If OK, I will update the proposal for the issue #73 = in the Dime Tracker

 

Best regards

 

JJacques 




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

 

--_000_E194C2E18676714DACA9C3A2516265D2026E8C54FR712WXCHMBA12z_-- From nobody Wed Oct 22 01:32:20 2014 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 BDA681A8AFA for ; Wed, 22 Oct 2014 01:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 91M9O18qvhwh for ; Wed, 22 Oct 2014 01:05:30 -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 BD89F1A8AF4 for ; Wed, 22 Oct 2014 01:05:30 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:54338 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgqvA-0005XH-3k for dime@ietf.org; Wed, 22 Oct 2014 01:05:29 -0700 Message-ID: <54476545.10706@usdonovans.com> Date: Wed, 22 Oct 2014 10:05:25 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------030604060706010001080803" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/0Q3mQQFejs0WPkAB0kAVf-uYvW8 X-Mailman-Approved-At: Wed, 22 Oct 2014 01:32:17 -0700 Subject: [Dime] Consistency, redundancy and editorial check 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, 22 Oct 2014 08:05:37 -0000 This is a multi-part message in MIME format. --------------030604060706010001080803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've done a consistency, redundancy and editorial check, with resulting changes, for all sections but the AVP sections (which I had already taken a pass at), the Overload Report Handling section, the Security section and the Appendices. I will work on the Overload Report Handling section next. I have checked the changes in to github. I have also attached the diff file. Regards, Steve --------------030604060706010001080803 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 2, line 34 skipping to change at page 2, line 34
4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12
4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12
4.2. Overload Report Processing . . . . . . . . . . . . . . . 13 4.2. Overload Report Processing . . . . . . . . . . . . . . . 13
4.2.1. Overload Control State . . . . . . . . . . . . . . . 13 4.2.1. Overload Control State . . . . . . . . . . . . . . . 13
4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16
4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17
4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 19 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 19
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 21 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 21
5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 22 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 21
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 23 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 22
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 23 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 22
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 23
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 23
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 24 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 24
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 25 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 24
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 25
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 26
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 26
7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27 7. Error Response Codes . . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28 8.2. New registries . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 29 9.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 28
9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 30 9.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 30
9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30 9.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . . 30
9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 31 9.4. End-to End-Security Issues . . . . . . . . . . . . . . . 30
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Issues left for future specifications . . . . . . . 33 Appendix A. Issues left for future specifications . . . . . . . 32
A.1. Additional traffic abatement algorithms . . . . . . . . . 33 A.1. Additional traffic abatement algorithms . . . . . . . . . 33
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 33 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 33
A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 33 A.3. DIAMETER_TOO_BUSY clarifications . . . . . . . . . . . . 33
Appendix B. Deployment Considerations . . . . . . . . . . . . . 33 Appendix B. Deployment Considerations . . . . . . . . . . . . . 33
Appendix C. Considerations for Applications Integrating the DOIC Appendix C. Considerations for Applications Integrating the DOIC
Solution . . . . . . . . . . . . . . . . . . . . . . 34 Solution . . . . . . . . . . . . . . . . . . . . . . 34
C.1. Application Classification . . . . . . . . . . . . . . . 34 C.1. Application Classification . . . . . . . . . . . . . . . 34
C.2. Application Type Overload Implications . . . . . . . . . 35 C.2. Application Type Overload Implications . . . . . . . . . 35
C.3. Request Transaction Classification . . . . . . . . . . . 36 C.3. Request Transaction Classification . . . . . . . . . . . 36
C.4. Request Type Overload Implications . . . . . . . . . . . 37 C.4. Request Type Overload Implications . . . . . . . . . . . 37
skipping to change at page 18, line 34 skipping to change at page 18, line 34
Note that a reacting node advertises support for the host and Note that a reacting node advertises support for the host and
realm report types by including the OC-Supported-Features AVP in realm report types by including the OC-Supported-Features AVP in
the request. Support for other report types must be explicitly the request. Support for other report types must be explicitly
indicated by a new feature bit in the OC-Feature-Vector AVP. indicated by a new feature bit in the OC-Feature-Vector AVP.
If OLR is for a new overload condition and there is no unexpired If OLR is for a new overload condition and there is no unexpired
overload report for previous overload conditions at any reacting node overload report for previous overload conditions at any reacting node
then the reporting node MAY set the sequence number to any value. then the reporting node MAY set the sequence number to any value.
The reporting node MAY update the overload report with new reduction The reacting node MAY update the overload report with new reduction
percentages. percentages. When doing so, the reacting node MUST increase the
sequence number in the new OLR sent.
The reporting node MAY extend the validatity duration for an existing
overload report by sending a OLR with either the same or a new
validity duration value.
When sending an overload report with new values in any of the sub
AVPs for an existing overload condition, the reporting node MUST
increase the sequence number in the new OLR sent.
When generating sequence numbers for new overload conditions, the new When generating sequence numbers for new overload conditions, the new
sequence number MUST be greater than any sequence number in an active sequence number MUST be greater than any sequence number in an active
(unexpired) overload report previously sent by the reporting node. (unexpired) overload report previously sent by the reporting node.
This property MUST hold over a reboot of the reporting node. This property MUST hold over a reboot of the reporting node.
A reporting node MAY rely on the OC-Validity-Duration AVP values for A reporting node MAY rely on the OC-Validity-Duration AVP values for
the implicit overload control state cleanup on the reacting node. the implicit overload control state cleanup on the reacting node.
However, it is RECOMMENDED that the reporting node always explicitly However, it is RECOMMENDED that the reporting node always explicitly
indicates the end of a overload condition. indicates the end of a overload condition.
The reporting node SHOULD indicate the end of an overload occurrence The reporting node SHOULD indicate the end of an overload occurrence
by sending a new OLR with OC-Validity-Duration set to a value of zero by sending a new OLR with OC-Validity-Duration set to a value of zero
("0"). The reporting node SHOULD insure that all reacting nodes ("0"). The reporting node SHOULD insure that all reacting nodes
receive the updated overload report. receive the updated overload report.
When a reporting node sends an OLR, it effectively delegates any
necessary throttling to downstream nodes. Therefore, the reporting
node SHOULD NOT apply throttling to the set of messages to which the
OLR applies. That is, the same candidate set of messages SHOULD NOT
be throttled multiple times.
However, when the reporting node sends and OLR downstream, it MAY
still be responsible to apply other abatement methods, such as
diversion, or request throttling requests for other reasons. For
example, an agent or server might have a configured rate limit for
each client, and throttle requests that exceed that limit, even if
such requests had already been candidates for throttling by
downstream nodes.
All OLRs sent have an expiration time calculated by adding the All OLRs sent have an expiration time calculated by adding the
validity-duration contained in the OLR to the time the message was validity-duration contained in the OLR to the time the message was
sent. Transit time for the OLR can be safely ignored. The sent. Transit time for the OLR can be safely ignored. The
reporting node can ensure that all reacting nodes have received reporting node can ensure that all reacting nodes have received
the OLR by continuing to send it in answer messages until the the OLR by continuing to send it in answer messages until the
expiration time for all OLRs sent for that overload contition have expiration time for all OLRs sent for that overload contition have
expired. expired.
This document assumes that there is a single source for realm-reports This document assumes that there is a single source for realm-reports
for a given realm, or that if multiple nodes can send realm reports, for a given realm, or that if multiple nodes can send realm reports,
 End of changes. 12 change blocks. 
36 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------030604060706010001080803-- From nobody Wed Oct 22 07:11:24 2014 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 42C101AC3F8 for ; Wed, 22 Oct 2014 07:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 U-gHgIhN3p-E for ; Wed, 22 Oct 2014 07:11:09 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 350EA1AC3E7 for ; Wed, 22 Oct 2014 07:10:05 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9MEA4Gd024193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2014 09:10:04 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <544754C5.7070809@usdonovans.com> Date: Wed, 22 Oct 2014 09:10:03 -0500 X-Mao-Original-Outgoing-Id: 435679803.798493-47bf52607783d04fcee0571e5d1ec593 Content-Transfer-Encoding: quoted-printable Message-Id: <86C5EF13-92F3-46B7-BEFB-3596FAD3F815@nostrum.com> References: <5444D8F9.9040906@usdonovans.com> <544754C5.7070809@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6Ze1RH1usje9SSfatZetNrKEho4 Cc: "dime@ietf.org" Subject: Re: [Dime] Resolution to issues 70 and 74 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, 22 Oct 2014 14:11:14 -0000 wfm > On Oct 22, 2014, at 1:55 AM, Steve Donovan = wrote: >=20 > The other way of wording this would be as follows: >=20 > A reporting node MUST NOT send overload reports of a type = that has not been > advertized as supported by the reacting node. >=20 > Which is an explicit double negation that is necessary to get the = point across. The above wording will be in the next revision of the = draft. I'm open to other wording if someone has a cleaner way of = getting this requirement across. >=20 > Regards, >=20 > Steve >=20 > On 10/20/14, 11:17 PM, Ben Campbell wrote: >> Slight normative language quibble: >>=20 >> "MUST only" is a bit of a strange construction from a 2119 = perspective, in that it implies a negation without an explicit NOT. I = think we really mean "MUST NOT unless...". >>=20 >>=20 >>> On Oct 20, 2014, at 4:42 AM, Steve Donovan = wrote: >>>=20 >>> I have removed the examples section and moved the "Application = Considerations" section to an appendix. >>>=20 >>> For issue 70 I also added the following wording to section 4.2.3: >>>=20 >>> A reporting node MUST only send overload reports of a type = advertised >>> as supported by the reacting node. >>>=20 >>> Note that a reacting node advertises support for the host and >>> realm report types by including the OC-Supported-Features AVP = in >>> the request. Support for other report types must be = explicitly >>> indicated by a new feature bit in the OC-Feature-Vector AVP. >>>=20 >>>=20 >>>=20 >>> The diff file is attached. >>>=20 >>> Regards, >>>=20 >>> Steve >>> _________________________________________= ______ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 From nobody Wed Oct 22 07:14:06 2014 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 33EE41AC426 for ; Wed, 22 Oct 2014 07:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jsMRZTHj9d7R for ; Wed, 22 Oct 2014 07:13:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 024191AC427 for ; Wed, 22 Oct 2014 07:11:27 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9MEBQhm024342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2014 09:11:27 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <54474FA9.3040300@usdonovans.com> Date: Wed, 22 Oct 2014 09:11:26 -0500 X-Mao-Original-Outgoing-Id: 435679886.483246-98c0b2942621edfdf41107a68d647470 Content-Transfer-Encoding: quoted-printable Message-Id: <54B8FD10-62AF-4F37-8BB8-AE4020087E8B@nostrum.com> References: <5444E8B9.8090002@usdonovans.com> <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> <22114_1413841265_54458171_22114_4224_1_6B7134B31289DC4FAF731D844122B36E8005B4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, <>> <1979_1413867197_5445E6BD_1979_10335_1_s8e3rg7h7yyc2r23mds3uefp.1413867190363@email.android.com> <5446190F.2070804@usdonovans.com> <99D5FF0E-2D2B-4DB1-8C9C-19296A8D1822@nostrum.com> <54474FA9.3040300@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/JKi4VpW1uaragYFLLwSYpwidvVg Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for error response wording (issue 85) 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, 22 Oct 2014 14:13:54 -0000 > On Oct 22, 2014, at 1:33 AM, Steve Donovan = wrote: >=20 > Ben, >=20 > I missed the other comment. The MUST wording you suggest will be in = the next revision of the -04 draft. >=20 > Yes on your question about the SHOULD. Do you think we need wording = saying that implementations can make other choices if they have good = reason? That's what SHOULD means on it's own. We might get push back to suggest = some potential "good reasons". (None come to mind at the moment...) >=20 > Steve >=20 > On 10/21/14, 4:46 PM, Ben Campbell wrote: >> Did we intend to include anything about Lionel's suggestion on = UNABLE_TO_DELIVER? (I am neutral on that--I just wanted to make sure we = didn't forget to consider it.) >>=20 >> I also have one comment inline. Otherwise it looks good to me. >>=20 >>=20 >>> On Oct 21, 2014, at 3:27 AM, Steve Donovan = wrote: >>>=20 >>> I have incorporated the following text into the document in the = existing, previously empty, section 7. Error Response Codes. >>>=20 >>> I will wait until tomorrow to close issue 85 to allow for discussion = of the proposed wording. >>>=20 >>> I have attached the diff as this wording is not in the draft. >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>> --- >>>=20 >>> When a DOIC node rejects a Diameter request due to throttling, = the >>> DOIC node needs to select the appropriate error response code. >> Do we have separate text saying the node MUST send an error? If not, = I suggest changing this to "... MUST respond with an appropriate error = response code." >>=20 >> The change from "the" to "an" was intentional. Since we are using = SHOULD below for the actual choice, I assume we intend to leave room for = an implementation to make other choices if it has a good reason. >>=20 >>=20 >>> This >>> determination is made based on the probability of the request >>> succeeding if retried on a different path. >>>=20 >>> The DIAMETER_TOO_BUSY response code SHOULD be used when the = request >>> is likely to succeed on a different path. >>>=20 >>> For instance, if the request arrived at the reporting node = without >>> a Destination-Host AVP then the reporting node might determine >>> that there is an alternative Diameter node that could = successfully >>> process the request and that retrying the transaction would = not >>> negatively impact the reporting node. >>>=20 >>> The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to >>> indicate that the request should not be retried. This is used = when >>> the request is not likely to succeed on a different path and = retrying >>> would consume valuable resources during an occurance of overload. >>>=20 >>> For instance, if the request arrived at the reporting node = with a >>> Destination-Host AVP populated with its own Diameter identity = then >>> the reporting node can assume that retrying the request would >>> result in it coming to the same reporting node. >>>=20 >>> A second example is when an agent that supports the DOIC = solution >>> is preforming the role of a reacting node for a non supporting >>> client. Requests that are rejected as a result of DOIC = throttling >>> in this scenario would generally be rejected with a >>> DIAMETER_UNABLE_TO_COMPLY response code. >>>=20 >>>=20 >>>=20 >>>=20 >>> On 10/21/14, 6:53 AM, lionel.morand@orange.com wrote: >>>> I agree. >>>>=20 >>>> Lionel >>>>=20 >>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>=20 >>>> ---- Ben Campbell a =E9crit ---- >>>>=20 >>>>=20 >>>>=20 >>>>> On Oct 20, 2014, at 4:41 PM, = >>>>> wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> I think that: >>>>> - TOO_BUSY should be restricted to server answer >>>>>=20 >>>> One of the reasons I think we need to state this by intended result = and not by role in the network, is that I expect that an overloaded = agent (according to the agent overload draft) might send TOO-BUSY. And a = server that acts as an overload authority for a realm might send = UNABLE-TO-[COMPLY or DELIVER] to a request that did not contain a = Destination-Host AVP. >>>>=20 >>>>=20 >>>>> - UNABLE_TO_COMPLY as answer to non-supporting DOIC when no = retransmission is required >>>>> - UNABLE_TO_DELIVER to supporting DOIC and to non-supporting DOIC = node when retransmission to an alternate peer could be better. >>>>>=20 >>>>> As a second step, we could enhance the answer message (in this = draft or in a separate draft if preferred) with an error message (e.g. = "Error-Diagnostic") that could provide further information to "new" node = that will be then able to adapt their behavior. >>>>> So a supporting DOIC receiving UNABLE_TO_DELIVER/TOO_BUSY with an = Error-Diagnostic set to e.g. "severe overload", besides the OLR in the = answer, will know that retransmission on the path or a on a different = path will likely cause the same error. If no error-diagnostic is sent = back or ignored by the non-supporting-DOOIC node, we will go back to the = situation prior this draft. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Lionel >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : DiME [ >>>>> mailto:dime-bounces@ietf.org >>>>> ] De la part de Ben Campbell >>>>> Envoy=E9 : lundi 20 octobre 2014 19:10 >>>>> =C0 : Steve Donovan >>>>> Cc : >>>>> dime@ietf.org >>>>>=20 >>>>> Objet : Re: [Dime] Proposal for error response wording (issue 85) >>>>>=20 >>>>> I agree that we should generalize these, but I think the direction = is not quite right. More inline: >>>>>=20 >>>>>=20 >>>>>> On Oct 20, 2014, at 5:49 AM, Steve Donovan = >>>>>> wrote: >>>>>>=20 >>>>>> We came to the following agreements on error responses: >>>>>>=20 >>>>>> - Servers rejecting a Diameter request due to an overload = condition should send a 3002 DIAMETER_TOO_BUSY error response. >>>>>>=20 >>>>>> - Agents rejecting a Diameter request due to an overload = condition should send a 5012 DIAMETER_UNABLE_TO_COMPLY. >>>>>>=20 >>>>>> I propose that we generalize this to the following: >>>>>>=20 >>>>>> - Reporting nodes rejecting a Diameter request due to an overload = condition SHOULD send a 3002 DIAMETER-TOO-BUSY error response. >>>>>>=20 >>>>>> - Reacting nodes rejecting a Diameter request due to an overload = condition SHOULD send a UNABLE-TO-COMPLY. >>>>>>=20 >>>>> I don't think we should state this in terms of reaction and = reporting nodes. I think we should generalize to expected behavior. = Also, in the case where the downstream node does not support DOIC, I'm = not sure it makes sense to say the throttling node is really a reporting = node (for that particular relationship.) >>>>>=20 >>>>> My suggestion is we say that, if the throttling node has = sufficient information to determine that the request is not likely to = succeed if retried on another path, it SHOULD send UNABLE-TO-COMPLY. If = it does not have that information, it SHOULD send TOO-BUSY. (we should = discuss why this is not a MUST if we have the conditionals in place.) >>>>>=20 >>>>> Then we could go on to say that a reaction node (or agent) would = typically fall under the first category, and a reporting node (or = server) would typically fall under the second. But there certainly may = be cases where a reacting node does not know if other paths could work, = and where a reporting node might know that they couldn't. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> This would mean that an agent acting as a reporting node (i.e.; = server doesn't support DOIC or agent is acting as a server front end) = would sent the TOO_BUSY response and an agent acting as a reacting node = (i.e.; a client doesn't support DOIC) then it sends a UNABLE_TO_COMPLY = response. >>>>>>=20 >>>>>> I propose adding this to a new section 4.2.4. The existing 4.2.4 = on agent behavior will be deleted. >>>>>>=20 >>>>>> I will hold off making this change until tomorrow (Tuesday = morning). >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Steve >>>>>>=20 >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>>=20 >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> _______________________________________________ >>>>> DiME mailing list >>>>>=20 >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>=20 >>>>>=20 >>>>> = __________________________________________________________________________= _______________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>>>> 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 >>>> = __________________________________________________________________________= _______________________________________________ >>>>=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 >>>>=20 >>> >>=20 >=20 From nobody Wed Oct 22 07:15:15 2014 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 5AE791AC3D9 for ; Wed, 22 Oct 2014 07:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7miImZKRxCsL for ; Wed, 22 Oct 2014 07:14:49 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 198371AC411 for ; Wed, 22 Oct 2014 07:11:59 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9MEBQhn024342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2014 09:11:58 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: <54B8FD10-62AF-4F37-8BB8-AE4020087E8B@nostrum.com> Date: Wed, 22 Oct 2014 09:11:58 -0500 X-Mao-Original-Outgoing-Id: 435679918.309216-a2125cc592345988ba51b859d0bcbdbd Content-Transfer-Encoding: quoted-printable Message-Id: References: <5444E8B9.8090002@usdonovans.com> <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> <22114_1413841265_54458171_22114_4224_1_6B7134B31289DC4FAF731D844122B36E8005B4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, <>> <1979_1413867197_5445E6BD_1979_10335_1_s8e3rg7h7yyc2r23mds3uefp.1413867190363@email.android.com> <5446190F.2070804@usdonovans.com> <99D5FF0E-2D2B-4DB1-8C9C-19296A8D1822@nostrum.com> <54474FA9.3040300@usdonovans.com> <54B8FD10-62AF-4F37-8BB8-AE4020087E8B@nostrum.com> To: Steve Donovan X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bvkjeIskxC7TWB-7huDlSjtnfjc Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for error response wording (issue 85) 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, 22 Oct 2014 14:14:59 -0000 > On Oct 22, 2014, at 9:11 AM, Ben Campbell wrote: >=20 >=20 >> On Oct 22, 2014, at 1:33 AM, Steve Donovan = wrote: >>=20 >> Ben, >>=20 >> I missed the other comment. The MUST wording you suggest will be in = the next revision of the -04 draft. >>=20 >> Yes on your question about the SHOULD. Do you think we need wording = saying that implementations can make other choices if they have good = reason? >=20 > That's what SHOULD means on it's own. We might get push back to = suggest some potential "good reasons". (None come to mind at the = moment...) >=20 >>=20 >> Steve >>=20 >> On 10/21/14, 4:46 PM, Ben Campbell wrote: >>> Did we intend to include anything about Lionel's suggestion on = UNABLE_TO_DELIVER? (I am neutral on that--I just wanted to make sure we = didn't forget to consider it.) >>>=20 >>> I also have one comment inline. Otherwise it looks good to me. >>>=20 >>>=20 >>>> On Oct 21, 2014, at 3:27 AM, Steve Donovan = wrote: >>>>=20 >>>> I have incorporated the following text into the document in the = existing, previously empty, section 7. Error Response Codes. >>>>=20 >>>> I will wait until tomorrow to close issue 85 to allow for = discussion of the proposed wording. >>>>=20 >>>> I have attached the diff as this wording is not in the draft. >>>>=20 >>>> Regards, >>>>=20 >>>> Steve >>>>=20 >>>> --- >>>>=20 >>>> When a DOIC node rejects a Diameter request due to throttling, = the >>>> DOIC node needs to select the appropriate error response code. >>> Do we have separate text saying the node MUST send an error? If not, = I suggest changing this to "... MUST respond with an appropriate error = response code." >>>=20 >>> The change from "the" to "an" was intentional. Since we are using = SHOULD below for the actual choice, I assume we intend to leave room for = an implementation to make other choices if it has a good reason. >>>=20 >>>=20 >>>> This >>>> determination is made based on the probability of the request >>>> succeeding if retried on a different path. >>>>=20 >>>> The DIAMETER_TOO_BUSY response code SHOULD be used when the = request >>>> is likely to succeed on a different path. >>>>=20 >>>> For instance, if the request arrived at the reporting node = without >>>> a Destination-Host AVP then the reporting node might determine >>>> that there is an alternative Diameter node that could = successfully >>>> process the request and that retrying the transaction would = not >>>> negatively impact the reporting node. >>>>=20 >>>> The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to >>>> indicate that the request should not be retried. This is used = when >>>> the request is not likely to succeed on a different path and = retrying >>>> would consume valuable resources during an occurance of overload. >>>>=20 >>>> For instance, if the request arrived at the reporting node = with a >>>> Destination-Host AVP populated with its own Diameter identity = then >>>> the reporting node can assume that retrying the request would >>>> result in it coming to the same reporting node. >>>>=20 >>>> A second example is when an agent that supports the DOIC = solution >>>> is preforming the role of a reacting node for a non supporting >>>> client. Requests that are rejected as a result of DOIC = throttling >>>> in this scenario would generally be rejected with a >>>> DIAMETER_UNABLE_TO_COMPLY response code. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 10/21/14, 6:53 AM, lionel.morand@orange.com wrote: >>>>> I agree. >>>>>=20 >>>>> Lionel >>>>>=20 >>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>=20 >>>>> ---- Ben Campbell a =E9crit ---- >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Oct 20, 2014, at 4:41 PM, = >>>>>> wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I think that: >>>>>> - TOO_BUSY should be restricted to server answer >>>>>>=20 >>>>> One of the reasons I think we need to state this by intended = result and not by role in the network, is that I expect that an = overloaded agent (according to the agent overload draft) might send = TOO-BUSY. And a server that acts as an overload authority for a realm = might send UNABLE-TO-[COMPLY or DELIVER] to a request that did not = contain a Destination-Host AVP. >>>>>=20 >>>>>=20 >>>>>> - UNABLE_TO_COMPLY as answer to non-supporting DOIC when no = retransmission is required >>>>>> - UNABLE_TO_DELIVER to supporting DOIC and to non-supporting DOIC = node when retransmission to an alternate peer could be better. >>>>>>=20 >>>>>> As a second step, we could enhance the answer message (in this = draft or in a separate draft if preferred) with an error message (e.g. = "Error-Diagnostic") that could provide further information to "new" node = that will be then able to adapt their behavior. >>>>>> So a supporting DOIC receiving UNABLE_TO_DELIVER/TOO_BUSY with an = Error-Diagnostic set to e.g. "severe overload", besides the OLR in the = answer, will know that retransmission on the path or a on a different = path will likely cause the same error. If no error-diagnostic is sent = back or ignored by the non-supporting-DOOIC node, we will go back to the = situation prior this draft. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Lionel >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : DiME [ >>>>>> mailto:dime-bounces@ietf.org >>>>>> ] De la part de Ben Campbell >>>>>> Envoy=E9 : lundi 20 octobre 2014 19:10 >>>>>> =C0 : Steve Donovan >>>>>> Cc : >>>>>> dime@ietf.org >>>>>>=20 >>>>>> Objet : Re: [Dime] Proposal for error response wording (issue 85) >>>>>>=20 >>>>>> I agree that we should generalize these, but I think the = direction is not quite right. More inline: >>>>>>=20 >>>>>>=20 >>>>>>> On Oct 20, 2014, at 5:49 AM, Steve Donovan = >>>>>>> wrote: >>>>>>>=20 >>>>>>> We came to the following agreements on error responses: >>>>>>>=20 >>>>>>> - Servers rejecting a Diameter request due to an overload = condition should send a 3002 DIAMETER_TOO_BUSY error response. >>>>>>>=20 >>>>>>> - Agents rejecting a Diameter request due to an overload = condition should send a 5012 DIAMETER_UNABLE_TO_COMPLY. >>>>>>>=20 >>>>>>> I propose that we generalize this to the following: >>>>>>>=20 >>>>>>> - Reporting nodes rejecting a Diameter request due to an = overload condition SHOULD send a 3002 DIAMETER-TOO-BUSY error response. >>>>>>>=20 >>>>>>> - Reacting nodes rejecting a Diameter request due to an overload = condition SHOULD send a UNABLE-TO-COMPLY. >>>>>>>=20 >>>>>> I don't think we should state this in terms of reaction and = reporting nodes. I think we should generalize to expected behavior. = Also, in the case where the downstream node does not support DOIC, I'm = not sure it makes sense to say the throttling node is really a reporting = node (for that particular relationship.) >>>>>>=20 >>>>>> My suggestion is we say that, if the throttling node has = sufficient information to determine that the request is not likely to = succeed if retried on another path, it SHOULD send UNABLE-TO-COMPLY. If = it does not have that information, it SHOULD send TOO-BUSY. (we should = discuss why this is not a MUST if we have the conditionals in place.) >>>>>>=20 >>>>>> Then we could go on to say that a reaction node (or agent) would = typically fall under the first category, and a reporting node (or = server) would typically fall under the second. But there certainly may = be cases where a reacting node does not know if other paths could work, = and where a reporting node might know that they couldn't. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> This would mean that an agent acting as a reporting node (i.e.; = server doesn't support DOIC or agent is acting as a server front end) = would sent the TOO_BUSY response and an agent acting as a reacting node = (i.e.; a client doesn't support DOIC) then it sends a UNABLE_TO_COMPLY = response. >>>>>>>=20 >>>>>>> I propose adding this to a new section 4.2.4. The existing = 4.2.4 on agent behavior will be deleted. >>>>>>>=20 >>>>>>> I will hold off making this change until tomorrow (Tuesday = morning). >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Steve >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>>=20 >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>>=20 >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>=20 >>>>>>=20 >>>>>> = __________________________________________________________________________= _______________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des = informations confidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>>>>> 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 >>>>> = __________________________________________________________________________= _______________________________________________ >>>>>=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 >>>>>=20 >>>> >>>=20 >>=20 >=20 From nobody Wed Oct 22 07:16:33 2014 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 45EEE1AC3E5 for ; Wed, 22 Oct 2014 07:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pcKZjaYv2i1W for ; Wed, 22 Oct 2014 07:16:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6B0931AC447 for ; Wed, 22 Oct 2014 07:13:34 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9MEDXu4024538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2014 09:13:34 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell In-Reply-To: Date: Wed, 22 Oct 2014 09:13:33 -0500 X-Mao-Original-Outgoing-Id: 435680013.030103-bd01eca0c4dd5c12f98488747346c9fc Content-Transfer-Encoding: quoted-printable Message-Id: <63360489-6C41-4A03-B590-59CE093254BE@nostrum.com> References: <5444E8B9.8090002@usdonovans.com> <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> <22114_1413841265_54458171_22114_4224_1_6B7134B31289DC4FAF731D844122B36E8005B4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, <>> <1979_1413867197_5445E6BD_1979_10335_1_s8e3rg7h7yyc2r23mds3uefp.1413867190363@email.android.com> <5446190F.2070804@usdonovans.com> <99D5FF0E-2D2B-4DB1-8C9C-19296A8D1822@nostrum.com> <54474FA9.3040300@usdonovans.com> <54B8FD10-62AF-4F37-8BB8-AE4020087E8B@nostrum.com> To: Steve Donovan X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1yZybmlxcr8mkw81tqg_UkZd1-Q Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for error response wording (issue 85) 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, 22 Oct 2014 14:16:30 -0000 Oops, hit sent early: > On Oct 22, 2014, at 9:11 AM, Ben Campbell wrote: >=20 >=20 >> On Oct 22, 2014, at 9:11 AM, Ben Campbell wrote: >>=20 >>=20 >>> On Oct 22, 2014, at 1:33 AM, Steve Donovan = wrote: >>>=20 >>> Ben, >>>=20 >>> I missed the other comment. The MUST wording you suggest will be in = the next revision of the -04 draft. >>>=20 >>> Yes on your question about the SHOULD. Do you think we need wording = saying that implementations can make other choices if they have good = reason? >>=20 >> That's what SHOULD means on it's own. We might get push back to = suggest some potential "good reasons". (None come to mind at the = moment...) >>=20 I guess one potential good reason would be if we (or someone) created = new error codes in the future to distinguish these scenarios from other = uses of the existing codes. We've talked about fixing that with a = diagnostic AVP, but that's not written in stone. From nobody Wed Oct 22 07:27:09 2014 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 ABA5A1ACC8C for ; Wed, 22 Oct 2014 07:27:04 -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 a1D4Gx1t0yFD for ; Wed, 22 Oct 2014 07:27:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299B01AC43D for ; Wed, 22 Oct 2014 07:26:54 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C5D2A22C336; Wed, 22 Oct 2014 16:26:52 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A52E427C085; Wed, 22 Oct 2014 16:26:52 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 16:26:52 +0200 From: To: Ben Campbell , Steve Donovan Thread-Topic: [Dime] Proposal for error response wording (issue 85) Thread-Index: AQHP7FOMzo+IEEAdVEGPqLkd/UJbyJw5F0KAgABpp+D//+1BAIAAjwkagAAadoCAAGnDgIABCIGAgACABgCAAAAnAIAAJVSQ Date: Wed, 22 Oct 2014 14:26:51 +0000 Message-ID: <19590_1413988012_5447BEAC_19590_5217_1_6B7134B31289DC4FAF731D844122B36E813EB3@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <5444E8B9.8090002@usdonovans.com> <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> <22114_1413841265_54458171_22114_4224_1_6B7134B31289DC4FAF731D844122B36E8005B4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, <>> <1979_1413867197_5445E6BD_1979_10335_1_s8e3rg7h7yyc2r23mds3uefp.1413867190363@email.android.com> <5446190F.2070804@usdonovans.com> <99D5FF0E-2D2B-4DB1-8C9C-19296A8D1822@nostrum.com> <54474FA9.3040300@usdonovans.com> <54B8FD10-62AF-4F37-8BB8-AE4020087E8B@nostrum.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.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.22.123024 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/rTnthW_7xhqOVR3U2UU-LWaaFYk Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for error response wording (issue 85) 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, 22 Oct 2014 14:27:04 -0000 I will try to come back with a proposal on UNABLE_TO_DELIVER and also the n= ew AVP after -04. The existing text for 04 is OK and can be anyway extended if required. Lionel -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: mercredi 22 octobre 2014 16:12 =C0=A0: Steve Donovan Cc=A0: MORAND Lionel IMT/OLN; dime@ietf.org Objet=A0: Re: [Dime] Proposal for error response wording (issue 85) > On Oct 22, 2014, at 9:11 AM, Ben Campbell wrote: >=20 >=20 >> On Oct 22, 2014, at 1:33 AM, Steve Donovan wr= ote: >>=20 >> Ben, >>=20 >> I missed the other comment. The MUST wording you suggest will be in the= next revision of the -04 draft. >>=20 >> Yes on your question about the SHOULD. Do you think we need wording say= ing that implementations can make other choices if they have good reason? >=20 > That's what SHOULD means on it's own. We might get push back to=20 > suggest some potential "good reasons". (None come to mind at the=20 > moment...) >=20 >>=20 >> Steve >>=20 >> On 10/21/14, 4:46 PM, Ben Campbell wrote: >>> Did we intend to include anything about Lionel's suggestion on=20 >>> UNABLE_TO_DELIVER? (I am neutral on that--I just wanted to make=20 >>> sure we didn't forget to consider it.) >>>=20 >>> I also have one comment inline. Otherwise it looks good to me. >>>=20 >>>=20 >>>> On Oct 21, 2014, at 3:27 AM, Steve Donovan = wrote: >>>>=20 >>>> I have incorporated the following text into the document in the existi= ng, previously empty, section 7. Error Response Codes. >>>>=20 >>>> I will wait until tomorrow to close issue 85 to allow for discussion o= f the proposed wording. >>>>=20 >>>> I have attached the diff as this wording is not in the draft. >>>>=20 >>>> Regards, >>>>=20 >>>> Steve >>>>=20 >>>> --- >>>>=20 >>>> When a DOIC node rejects a Diameter request due to throttling, the >>>> DOIC node needs to select the appropriate error response code. >>> Do we have separate text saying the node MUST send an error? If not, I = suggest changing this to "... MUST respond with an appropriate error respon= se code." >>>=20 >>> The change from "the" to "an" was intentional. Since we are using SHOUL= D below for the actual choice, I assume we intend to leave room for an impl= ementation to make other choices if it has a good reason. >>>=20 >>>=20 >>>> This >>>> determination is made based on the probability of the request >>>> succeeding if retried on a different path. >>>>=20 >>>> The DIAMETER_TOO_BUSY response code SHOULD be used when the request >>>> is likely to succeed on a different path. >>>>=20 >>>> For instance, if the request arrived at the reporting node without >>>> a Destination-Host AVP then the reporting node might determine >>>> that there is an alternative Diameter node that could successfully >>>> process the request and that retrying the transaction would not >>>> negatively impact the reporting node. >>>>=20 >>>> The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to >>>> indicate that the request should not be retried. This is used when >>>> the request is not likely to succeed on a different path and retrying >>>> would consume valuable resources during an occurance of overload. >>>>=20 >>>> For instance, if the request arrived at the reporting node with a >>>> Destination-Host AVP populated with its own Diameter identity then >>>> the reporting node can assume that retrying the request would >>>> result in it coming to the same reporting node. >>>>=20 >>>> A second example is when an agent that supports the DOIC solution >>>> is preforming the role of a reacting node for a non supporting >>>> client. Requests that are rejected as a result of DOIC throttling >>>> in this scenario would generally be rejected with a >>>> DIAMETER_UNABLE_TO_COMPLY response code. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 10/21/14, 6:53 AM, lionel.morand@orange.com wrote: >>>>> I agree. >>>>>=20 >>>>> Lionel >>>>>=20 >>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange >>>>>=20 >>>>> ---- Ben Campbell a =E9crit ---- >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Oct 20, 2014, at 4:41 PM, =20 >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I think that: >>>>>> - TOO_BUSY should be restricted to server answer >>>>>>=20 >>>>> One of the reasons I think we need to state this by intended result a= nd not by role in the network, is that I expect that an overloaded agent (a= ccording to the agent overload draft) might send TOO-BUSY. And a server tha= t acts as an overload authority for a realm might send UNABLE-TO-[COMPLY or= DELIVER] to a request that did not contain a Destination-Host AVP. >>>>>=20 >>>>>=20 >>>>>> - UNABLE_TO_COMPLY as answer to non-supporting DOIC when no=20 >>>>>> retransmission is required >>>>>> - UNABLE_TO_DELIVER to supporting DOIC and to non-supporting DOIC no= de when retransmission to an alternate peer could be better. >>>>>>=20 >>>>>> As a second step, we could enhance the answer message (in this draft= or in a separate draft if preferred) with an error message (e.g. "Error-Di= agnostic") that could provide further information to "new" node that will b= e then able to adapt their behavior. >>>>>> So a supporting DOIC receiving UNABLE_TO_DELIVER/TOO_BUSY with an Er= ror-Diagnostic set to e.g. "severe overload", besides the OLR in the answer= , will know that retransmission on the path or a on a different path will l= ikely cause the same error. If no error-diagnostic is sent back or ignored = by the non-supporting-DOOIC node, we will go back to the situation prior th= is draft. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Lionel >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : DiME [ >>>>>> mailto:dime-bounces@ietf.org >>>>>> ] De la part de Ben Campbell >>>>>> Envoy=E9 : lundi 20 octobre 2014 19:10 =C0 : Steve Donovan Cc : >>>>>> dime@ietf.org >>>>>>=20 >>>>>> Objet : Re: [Dime] Proposal for error response wording (issue 85) >>>>>>=20 >>>>>> I agree that we should generalize these, but I think the direction i= s not quite right. More inline: >>>>>>=20 >>>>>>=20 >>>>>>> On Oct 20, 2014, at 5:49 AM, Steve Donovan=20 >>>>>>> >>>>>>> wrote: >>>>>>>=20 >>>>>>> We came to the following agreements on error responses: >>>>>>>=20 >>>>>>> - Servers rejecting a Diameter request due to an overload condition= should send a 3002 DIAMETER_TOO_BUSY error response. >>>>>>>=20 >>>>>>> - Agents rejecting a Diameter request due to an overload condition = should send a 5012 DIAMETER_UNABLE_TO_COMPLY. >>>>>>>=20 >>>>>>> I propose that we generalize this to the following: >>>>>>>=20 >>>>>>> - Reporting nodes rejecting a Diameter request due to an overload c= ondition SHOULD send a 3002 DIAMETER-TOO-BUSY error response. >>>>>>>=20 >>>>>>> - Reacting nodes rejecting a Diameter request due to an overload co= ndition SHOULD send a UNABLE-TO-COMPLY. >>>>>>>=20 >>>>>> I don't think we should state this in terms of reaction and=20 >>>>>> reporting nodes. I think we should generalize to expected=20 >>>>>> behavior. Also, in the case where the downstream node does not=20 >>>>>> support DOIC, I'm not sure it makes sense to say the throttling=20 >>>>>> node is really a reporting node (for that particular=20 >>>>>> relationship.) >>>>>>=20 >>>>>> My suggestion is we say that, if the throttling node has sufficient = information to determine that the request is not likely to succeed if retri= ed on another path, it SHOULD send UNABLE-TO-COMPLY. If it does not have th= at information, it SHOULD send TOO-BUSY. (we should discuss why this is n= ot a MUST if we have the conditionals in place.) >>>>>>=20 >>>>>> Then we could go on to say that a reaction node (or agent) would typ= ically fall under the first category, and a reporting node (or server) woul= d typically fall under the second. But there certainly may be cases where a= reacting node does not know if other paths could work, and where a reporti= ng node might know that they couldn't. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> This would mean that an agent acting as a reporting node (i.e.; ser= ver doesn't support DOIC or agent is acting as a server front end) would se= nt the TOO_BUSY response and an agent acting as a reacting node (i.e.; a cl= ient doesn't support DOIC) then it sends a UNABLE_TO_COMPLY response. >>>>>>>=20 >>>>>>> I propose adding this to a new section 4.2.4. The existing 4.2.4 o= n agent behavior will be deleted. >>>>>>>=20 >>>>>>> I will hold off making this change until tomorrow (Tuesday morning). >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Steve >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>>=20 >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>>=20 >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>=20 >>>>>>=20 >>>>>> _________________________________________________________________ >>>>>> ________________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des=20 >>>>>> informations confidentielles ou privilegiees et ne doivent donc=20 >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteur= et le detruire ainsi que les pieces jointes. Les messages electroniques et= ant susceptibles d'alteration, Orange decline toute responsabilite si ce me= ssage a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or=20 >>>>>> 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 a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>>=20 >>>>> __________________________________________________________________ >>>>> _______________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>>>> ce message par erreur, veuillez 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 responsabilite si ce message a ete= altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or=20 >>>>> 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 an= d 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 >>>>>=20 >>>> >>> draft-ietf-dime-ovli-04.txt.html> >>>=20 >>=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, 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 22 07:51:55 2014 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 277FB1ACD1E for ; Wed, 22 Oct 2014 07:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hmNN2tYR4ZDr for ; Wed, 22 Oct 2014 07:51:46 -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 C86651ACD12 for ; Wed, 22 Oct 2014 07:51:46 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:55331 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgxGI-0000wb-7J; Wed, 22 Oct 2014 07:51:45 -0700 Message-ID: <5447C47C.4070404@usdonovans.com> Date: Wed, 22 Oct 2014 16:51:40 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, Ben Campbell References: <5444E8B9.8090002@usdonovans.com> <28879012-29FA-43F1-83EE-4B2A8539C7D8@nostrum.com> <22114_1413841265_54458171_22114_4224_1_6B7134B31289DC4FAF731D844122B36E8005B4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, <>> <1979_1413867197_5445E6BD_1979_10335_1_s8e3rg7h7yyc2r23mds3uefp.1413867190363@email.android.com> <5446190F.2070804@usdonovans.com> <99D5FF0E-2D2B-4DB1-8C9C-19296A8D1822@nostrum.com> <54474FA9.3040300@usdonovans.com> <54B8FD10-62AF-4F37-8BB8-AE4020087E8B@nostrum.com> <19590_1413988012_5447BEAC_19590_5217_1_6B7134B31289DC4FAF731D844122B36E813EB3@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <19590_1413988012_5447BEAC_19590_5217_1_6B7134B31289DC4FAF731D844122B36E813EB3@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Jdb_08k1Om40u3EZ9zN-amMbYJE Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for error response wording (issue 85) 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, 22 Oct 2014 14:51:49 -0000 Perfect, thanks. Steve On 10/22/14, 4:26 PM, lionel.morand@orange.com wrote: > I will try to come back with a proposal on UNABLE_TO_DELIVER and also the new AVP after -04. > The existing text for 04 is OK and can be anyway extended if required. > > Lionel > > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com] > Envoyé : mercredi 22 octobre 2014 16:12 > À : Steve Donovan > Cc : MORAND Lionel IMT/OLN; dime@ietf.org > Objet : Re: [Dime] Proposal for error response wording (issue 85) > > >> On Oct 22, 2014, at 9:11 AM, Ben Campbell wrote: >> >> >>> On Oct 22, 2014, at 1:33 AM, Steve Donovan wrote: >>> >>> Ben, >>> >>> I missed the other comment. The MUST wording you suggest will be in the next revision of the -04 draft. >>> >>> Yes on your question about the SHOULD. Do you think we need wording saying that implementations can make other choices if they have good reason? >> That's what SHOULD means on it's own. We might get push back to >> suggest some potential "good reasons". (None come to mind at the >> moment...) >> >>> Steve >>> >>> On 10/21/14, 4:46 PM, Ben Campbell wrote: >>>> Did we intend to include anything about Lionel's suggestion on >>>> UNABLE_TO_DELIVER? (I am neutral on that--I just wanted to make >>>> sure we didn't forget to consider it.) >>>> >>>> I also have one comment inline. Otherwise it looks good to me. >>>> >>>> >>>>> On Oct 21, 2014, at 3:27 AM, Steve Donovan wrote: >>>>> >>>>> I have incorporated the following text into the document in the existing, previously empty, section 7. Error Response Codes. >>>>> >>>>> I will wait until tomorrow to close issue 85 to allow for discussion of the proposed wording. >>>>> >>>>> I have attached the diff as this wording is not in the draft. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> >>>>> --- >>>>> >>>>> When a DOIC node rejects a Diameter request due to throttling, the >>>>> DOIC node needs to select the appropriate error response code. >>>> Do we have separate text saying the node MUST send an error? If not, I suggest changing this to "... MUST respond with an appropriate error response code." >>>> >>>> The change from "the" to "an" was intentional. Since we are using SHOULD below for the actual choice, I assume we intend to leave room for an implementation to make other choices if it has a good reason. >>>> >>>> >>>>> This >>>>> determination is made based on the probability of the request >>>>> succeeding if retried on a different path. >>>>> >>>>> The DIAMETER_TOO_BUSY response code SHOULD be used when the request >>>>> is likely to succeed on a different path. >>>>> >>>>> For instance, if the request arrived at the reporting node without >>>>> a Destination-Host AVP then the reporting node might determine >>>>> that there is an alternative Diameter node that could successfully >>>>> process the request and that retrying the transaction would not >>>>> negatively impact the reporting node. >>>>> >>>>> The DIAMETER_UNABLE_TO_COMPLY response code SHOULD be used to >>>>> indicate that the request should not be retried. This is used when >>>>> the request is not likely to succeed on a different path and retrying >>>>> would consume valuable resources during an occurance of overload. >>>>> >>>>> For instance, if the request arrived at the reporting node with a >>>>> Destination-Host AVP populated with its own Diameter identity then >>>>> the reporting node can assume that retrying the request would >>>>> result in it coming to the same reporting node. >>>>> >>>>> A second example is when an agent that supports the DOIC solution >>>>> is preforming the role of a reacting node for a non supporting >>>>> client. Requests that are rejected as a result of DOIC throttling >>>>> in this scenario would generally be rejected with a >>>>> DIAMETER_UNABLE_TO_COMPLY response code. >>>>> >>>>> >>>>> >>>>> >>>>> On 10/21/14, 6:53 AM, lionel.morand@orange.com wrote: >>>>>> I agree. >>>>>> >>>>>> Lionel >>>>>> >>>>>> Envoyé depuis mon Sony Xperia SP d'Orange >>>>>> >>>>>> ---- Ben Campbell a écrit ---- >>>>>> >>>>>> >>>>>> >>>>>>> On Oct 20, 2014, at 4:41 PM, >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I think that: >>>>>>> - TOO_BUSY should be restricted to server answer >>>>>>> >>>>>> One of the reasons I think we need to state this by intended result and not by role in the network, is that I expect that an overloaded agent (according to the agent overload draft) might send TOO-BUSY. And a server that acts as an overload authority for a realm might send UNABLE-TO-[COMPLY or DELIVER] to a request that did not contain a Destination-Host AVP. >>>>>> >>>>>> >>>>>>> - UNABLE_TO_COMPLY as answer to non-supporting DOIC when no >>>>>>> retransmission is required >>>>>>> - UNABLE_TO_DELIVER to supporting DOIC and to non-supporting DOIC node when retransmission to an alternate peer could be better. >>>>>>> >>>>>>> As a second step, we could enhance the answer message (in this draft or in a separate draft if preferred) with an error message (e.g. "Error-Diagnostic") that could provide further information to "new" node that will be then able to adapt their behavior. >>>>>>> So a supporting DOIC receiving UNABLE_TO_DELIVER/TOO_BUSY with an Error-Diagnostic set to e.g. "severe overload", besides the OLR in the answer, will know that retransmission on the path or a on a different path will likely cause the same error. If no error-diagnostic is sent back or ignored by the non-supporting-DOOIC node, we will go back to the situation prior this draft. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Lionel >>>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : DiME [ >>>>>>> mailto:dime-bounces@ietf.org >>>>>>> ] De la part de Ben Campbell >>>>>>> Envoyé : lundi 20 octobre 2014 19:10 À : Steve Donovan Cc : >>>>>>> dime@ietf.org >>>>>>> >>>>>>> Objet : Re: [Dime] Proposal for error response wording (issue 85) >>>>>>> >>>>>>> I agree that we should generalize these, but I think the direction is not quite right. More inline: >>>>>>> >>>>>>> >>>>>>>> On Oct 20, 2014, at 5:49 AM, Steve Donovan >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> We came to the following agreements on error responses: >>>>>>>> >>>>>>>> - Servers rejecting a Diameter request due to an overload condition should send a 3002 DIAMETER_TOO_BUSY error response. >>>>>>>> >>>>>>>> - Agents rejecting a Diameter request due to an overload condition should send a 5012 DIAMETER_UNABLE_TO_COMPLY. >>>>>>>> >>>>>>>> I propose that we generalize this to the following: >>>>>>>> >>>>>>>> - Reporting nodes rejecting a Diameter request due to an overload condition SHOULD send a 3002 DIAMETER-TOO-BUSY error response. >>>>>>>> >>>>>>>> - Reacting nodes rejecting a Diameter request due to an overload condition SHOULD send a UNABLE-TO-COMPLY. >>>>>>>> >>>>>>> I don't think we should state this in terms of reaction and >>>>>>> reporting nodes. I think we should generalize to expected >>>>>>> behavior. Also, in the case where the downstream node does not >>>>>>> support DOIC, I'm not sure it makes sense to say the throttling >>>>>>> node is really a reporting node (for that particular >>>>>>> relationship.) >>>>>>> >>>>>>> My suggestion is we say that, if the throttling node has sufficient information to determine that the request is not likely to succeed if retried on another path, it SHOULD send UNABLE-TO-COMPLY. If it does not have that information, it SHOULD send TOO-BUSY. (we should discuss why this is not a MUST if we have the conditionals in place.) >>>>>>> >>>>>>> Then we could go on to say that a reaction node (or agent) would typically fall under the first category, and a reporting node (or server) would typically fall under the second. But there certainly may be cases where a reacting node does not know if other paths could work, and where a reporting node might know that they couldn't. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> This would mean that an agent acting as a reporting node (i.e.; server doesn't support DOIC or agent is acting as a server front end) would sent the TOO_BUSY response and an agent acting as a reacting node (i.e.; a client doesn't support DOIC) then it sends a UNABLE_TO_COMPLY response. >>>>>>>> >>>>>>>> I propose adding this to a new section 4.2.4. The existing 4.2.4 on agent behavior will be deleted. >>>>>>>> >>>>>>>> I will hold off making this change until tomorrow (Tuesday morning). >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>> >>>> draft-ietf-dime-ovli-04.txt.html> > > _________________________________________________________________________________________________________________________ > > 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. > > From nobody Wed Oct 22 09:36:04 2014 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 9FB3D1A910E for ; Wed, 22 Oct 2014 06:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 0AGdg2U1j06j for ; Wed, 22 Oct 2014 06:23:07 -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 848781A90E0 for ; Wed, 22 Oct 2014 06:23:07 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:54949 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgvsW-0008Ba-Gd for dime@ietf.org; Wed, 22 Oct 2014 06:23:06 -0700 Message-ID: <5447AFB6.3060400@usdonovans.com> Date: Wed, 22 Oct 2014 15:23:02 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------050001050707070804040105" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/TUkzGju-GqQANXFVId-7v8RalLI X-Mailman-Approved-At: Wed, 22 Oct 2014 09:36:01 -0700 Subject: [Dime] Rewrite of Overload Report Handling Section 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, 22 Oct 2014 13:23:16 -0000 This is a multi-part message in MIME format. --------------050001050707070804040105 Content-Type: multipart/alternative; boundary="------------090507060303030408070604" --------------090507060303030408070604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I have done an extensive rewrite of the Overload Report Handling section. The requirements in the original version were split unevenly between various topics, including repeating of behavior from the Capability Announcement section. I split the requirement between the following: - Structure of the OCS, with a section for reacting nodes and a section for reporting nodes - Behavior related to managing OCS entries, with a section for reacting nodes and a section for reporting nodes - Behavior driven by OCS entries (i.e.; behavior when there is an active OCS entry), with a section for reacting nodes and a section for reporting nodes. Given the scope of the changes, I have attached a .txt document that contains the original section and a .txt document that contains the new section. I have also attach a diff file for those how prefers those. I have checked these changes into github. Bon appétit. Regards, Steve --------------090507060303030408070604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have done an extensive rewrite of the Overload Report Handling section.

The requirements in the original version were split unevenly between various topics, including repeating of behavior from the Capability Announcement section.

I split the requirement between the following:
- Structure of the OCS, with a section for reacting nodes and a section for reporting nodes
- Behavior related to managing OCS entries, with a section for reacting nodes and a section for reporting nodes
- Behavior driven by OCS entries (i.e.; behavior when there is an active OCS entry), with a section for reacting nodes and a section for reporting nodes.

Given the scope of the changes, I have attached a .txt document that contains the original section and a .txt document that contains the new section.  I have also attach a diff file for those how prefers those.

I have checked these changes into github.

Bon appétit.

Regards,

Steve

--------------090507060303030408070604-- --------------050001050707070804040105 Content-Type: text/plain; charset=UTF-8; name="original-overload-report-handling.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="original-overload-report-handling.txt" 4.2. Overload Report Processing 4.2.1. Overload Control State Both reacting and reporting nodes maintain Overload Control State (OCS) for active overload conditions. 4.2.1.1. Overload Control State for Reacting Nodes A reacting node maintains the following OCS per supported Diameter application (the actual information stored is an implementation decision): o A host-type Overload Control State for each Destination-Host to which it sends host-type requests and o A realm-type Overload Control State for each Destination-Realm to which it sends realm-type requests. A host-type OCS entry may be identified by the pair of Application-Id and Host-Id. A realm-type OCS entry may be identified by the pair of Application- Id and Realm-Id. The host-type and realm-type OCS entries could include the following information: o Sequence number (as received in OC-OLR) o Time of expiry (derived from validity duration as received in the OC-OLR AVP and time of reception of the message carrying OC-OLR AVP) o Selected Abatement Algorithm (as received in OC-Supported-Features AVP) o Abatement Algorithm specific input data (as received within the OC-OLR AVP, for example, Reduction Percentage for the Loss abatement algorithm) 4.2.1.2. Overload Control States for Reporting Nodes A reporting node maintains OCS entries per supported Diameter application and per supported (and eventually selected) Abatement Algorithm. Korhonen, et al. Expires April 25, 2015 [Page 14] Internet-Draft DOIC October 2014 An OCS entry may be identified by the pair of Application-Id and Abatement Algorithm. The OCS entry for a given pair of Application and Abatement Algorithm could include the information (the actual information stored is an implementation decision): o Report type o Sequence number o Validity Duration o Expiration Time o Algorithm specific input data (for example, the Reduction Percentage for the Loss Abatement Algorithm) 4.2.1.3. Reacting Node Maintainence of Overload Control State When a reacting node receives an OC-OLR AVP, it MUST determine if it is for an existing or new overload condition. The OLR is for an existing overload condition if the reacting node has an OCS that matches the received OLR. For a host report-type this means it matches the app-id and host-id in an existing host OCS entry. For a realm report-type this means it matches the app-id and realm-id in an existing realm OCS entry. If the OLR is for an existing overload condition then it MUST determine if the OLR is a retransmission or an update to the existing OLR. If the sequence number for the received OLR is greater than the sequence number stored in the matching OCS entry then the reacting node MUST update the matching OCS entry. If the sequence number for the received OLR is less than or equal to the sequence number in the matching OCS entry then the reacting node MUST silently ignore the received OLR. The matching OCS MUST NOT be updated in this case. If the received OLR is for a new overload condition then the reacting node MUST generate a new OCS entry for the overload condition. Korhonen, et al. Expires April 25, 2015 [Page 15] Internet-Draft DOIC October 2014 For a host report-type this means it creates on OCS entry with the app-id of the application-id in the received message and host-id of the Origin-Host in the received message. For a realm report-type this means it creates on OCS entry with the app-id of the application-id in the received message and realm-id of the Origin-Realm in the received message. If the received OLR contains a validity duration of zero ("0") then the reacting node MUST update the OCS entry as being expired. Note that it is not necessarily appropriate to delete the OCS entry, as there is recommended behavior that the reacting node slowly returns to full traffic when ending an overload abatement period. The reacting node does not delete an OCS when receiving an answer message that does not contain an OC-OLR AVP (i.e. absence of OLR means "no change"). 4.2.1.4. Reporting Node Maintainence of Overload Control State A reporting node SHOULD create a new OCS entry when entering an overload condition. If the reporting node knows through absence of the OC-Supported- Features AVP in received messages that there are no reacting nodes supporting DOIC then the reporting node can choose to not create OCS entries. The reporting node MUST update an OCS entry when it needs to adjust the validity duration of the overload contition at reacting nodes. For instance, if the reporting node wishes to instruct reacting nodes to continue overload abatement for a longer period of time that originally communicated. This also applies if the reporting node wishes to shorten the period of time that overload abatement is to continue. A reporting node MUST update an OCS entry when it wishes to adjust the any abatement algorithm specific parameters, including the reduction percentage used for the Loss abatement algorithm. For instance, if the reporting node wishes to change the reduction percentage either higher, if the overload condition has worsened, or lower, if the overload condition has improved, then the reporting node would update the appropriate OCS entry. Korhonen, et al. Expires April 25, 2015 [Page 16] Internet-Draft DOIC October 2014 The reporting node MUST update the sequence number associated with the OCS entry anytime the contents of the OCS entry are changed. This will result in a new sequence number being sent to reacing nodes, instructing the reacting nodes to process the OC-OLR AVP. If the OLR is for a new overload condition and there is no unexpired overload report for previous overload conditions at any reacting node then the reporting node MAY set the sequence number to any value. When generating sequence numbers for new overload conditions, the new sequence number MUST be greater than any sequence number in an active (unexpired) overload report previously sent by the reporting node. This property MUST hold over a reboot of the reporting node. A reporting node MUST update an OCS entry with a validity duration of zero ("0") when the overload condition ends. The reporting node MUST keep an OCS entry with a validity duration of zero ("0") for a period of time long enough to ensure that any reacting node OCS entry created as a result of the overload condition in the reporting node exists. This period of time can be determined by calculating the time the last overload report for the overload condition was sent plus the validity duration included in that overload report. 4.2.2. Reacting Node Behavior Whenever a reacting node sends a request it MUST first determine if that request matches an active (non expired) OCS. If the request matches and active OCS then the reacting number MUST consider the request MUST for abatement treatment according to the abatement algorithm stored in the OCS. For the Loss abatement algorithm defined in this specification, see Section 5 for the abatement logic applied. If the reacting node is an agent then it MUST send an appropriate error as defined in section Section 7. In the case that the OCS entry validity duration expires or has a validity duration of zero ("0"), meaning that it the reporting node has explicitly signaled the end of the overload condition then abatement associated with the overload report MUST be ended in a controlled fashion. Korhonen, et al. Expires April 25, 2015 [Page 17] Internet-Draft DOIC October 2014 4.2.3. Reporting Node Behavior The operation on the reporting node is straight forward. If there is an active OCS entry then the reporting node SHOULD include the OC-OLR AVP in all answer messages to requests that contain the OC-Supported-Features AVP and that match the active OCS entry. A request matches if the application-id in the request matches the application-id in any active OCS entry and if the report-type in the OCS entry matches a report-type supported by the reporting node as indicated in the OC-Supported-Features AVP. The contents of the OC-OLR AVP MUST contain all information necessary for the abatement algorithm indicated in the OC-Supported-Features message also included in the answer message. A reporting node MAY choose to not resend an overload report to a reacting node if it can guarantee that this overload report is already active in the reacting node. Note - In some cases (e.g. when there are one or multiple agents in the path between reporting and reacting nodes, or when overload reports are discarded by reacting nodes) the reporting node may not be able to guarantee that the reacting node has received the report. A reporting node MUST NOT send overload reports of a type that has not been advertized as supported by the reacting node. Note that a reacting node advertises support for the host and realm report types by including the OC-Supported-Features AVP in the request. Support for other report types must be explicitly indicated by a new feature bit in the OC-Feature-Vector AVP. A reporting node MAY rely on the OC-Validity-Duration AVP values for the implicit overload control state cleanup on the reacting node. However, it is RECOMMENDED that the reporting node always explicitly indicates the end of a overload condition. The reporting node SHOULD indicate the end of an overload occurrence by sending a new OLR with OC-Validity-Duration set to a value of zero ("0"). The reporting node SHOULD insure that all reacting nodes receive the updated overload report. All OLRs sent have an expiration time calculated by adding the validity-duration contained in the OLR to the time the message was Korhonen, et al. Expires April 25, 2015 [Page 18] Internet-Draft DOIC October 2014 sent. Transit time for the OLR can be safely ignored. The reporting node can ensure that all reacting nodes have received the OLR by continuing to send it in answer messages until the expiration time for all OLRs sent for that overload contition have expired. When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes. Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the OLR applies. That is, the same candidate set of messages SHOULD NOT be throttled multiple times. However, when the reporting node sends and OLR downstream, it MAY still be responsible to apply other abatement methods, such as diversion, or request throttling requests for other reasons. For example, an agent or server might have a configured rate limit for each client, and throttle requests that exceed that limit, even if such requests had already been candidates for throttling by downstream nodes. This document assumes that there is a single source for realm-reports for a given realm, or that if multiple nodes can send realm reports, that each such node has full knowledge of the overload state of the entire realm. A reacting node cannot distinguish between receiving realm-reports from a single node, or from multiple nodes. If multiple such nodes exist, they MUST ensure that realm-reports are kept in sync. This includes synchronizing the sequence numbers as well as the reported overload state. The method of doing so is up to the implementation. One way to keep the sequence numbers in sync is to generate the sequence numbers based on system time. Editor's Note: There is not yet consensus on the above two paragraphs. 4.3. Protocol Extensibility The overload control solution can be extended, e.g. with new traffic abatement algorithms, new report types or other new functionality. When defining a new extension a new feature bit MUST be defined for the OC-Feature-Vector. This feature bit is used to communicate support for the new feature. The extention MAY define new AVPs for use in DOIC Capability Anouncement and for use in DOIC Overload reporting. These new AVP SHOULD be defined to be extensions to the OC-Supported-Features and OC-OLR AVPs defined in this document. Korhonen, et al. Expires April 25, 2015 [Page 19] Internet-Draft DOIC October 2014 It should be noted that [RFC6733] defined Grouped AVP extension mechanisms apply. This allows, for example, defining a new feature that is mandatory to be understood even when piggybacked on an existing applications. The handling of feature bits in the OC-Feature-Vector AVP that are not associated with overload abatement algorithms MUST be specified by the extensions that define the features. When defining new report type values, the corresponding specification MUST define the semantics of the new report types and how they affect the OC-OLR AVP handling. The specification MUST also reserve a corresponding new feature in the OC-Feature-Vector AVP. The OC-OLR AVP can be expanded with optional sub-AVPs only if a legacy DOIC implementation can safely ignore them without breaking backward compatibility for the given OC-Report-Type AVP value. If the new sub-AVPs imply new semantics for handling the indicated report type, then a new OC-Report-Type AVP value MUST be defined. New features (feature bits in the OC-Feature-Vector AVP) and report types (in the OC-Report-Type AVP) MUST be registered with IANA. As with any Diameter specification, new AVPs MUST also be registered with IANA. See Section 8 for the required procedures. --------------050001050707070804040105 Content-Type: text/plain; charset=UTF-8; name="new-overload-report-handling.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="new-overload-report-handling.txt" 4.2. Overload Report Processing 4.2.1. Overload Control State Both reacting and reporting nodes maintain Overload Control State (OCS) for active overload conditions. 4.2.1.1. Overload Control State for Reacting Nodes A reacting node SHOULD maintain the following OCS per supported Diameter application: o A host-type OCS entry for each Destination-Host to which it sends host-type requests and o A realm-type OCS entry for each Destination-Realm to which it sends realm-type requests. A host-type OCS entry MAY be identified by the pair of Application-Id and Host-Id. A realm-type OCS entry MAY be identified by the pair of Application- Id and Realm-Id. The host-type and realm-type OCS entries MAY include the following information (the actual information stored is an implementation decision): o Sequence number (as received in OC-OLR) o Time of expiry (derived from validity duration as received in the OC-OLR AVP and time of reception of the message carrying OC-OLR AVP) o Selected Abatement Algorithm (as received in OC-Supported-Features AVP) o Abatement Algorithm specific input data (as received within the OC-OLR AVP, for example, Reduction Percentage for the Loss abatement algorithm) 4.2.1.2. Overload Control State for Reporting Nodes A reporting node SHOULD maintain OCS entries per supported Diameter application and per supported (and eventually selected) Abatement Algorithm. Korhonen, et al. Expires April 25, 2015 [Page 14] Internet-Draft DOIC October 2014 An OCS entry MAY be identified by the pair of Application-Id and Abatement Algorithm. The OCS entry for a given pair of Application and Abatement Algorithm MAY include the information (the actual information stored is an implementation decision): o Report type o Sequence number o Validity Duration o Expiration Time o Algorithm specific input data (for example, the Reduction Percentage for the Loss Abatement Algorithm) 4.2.1.3. Reacting Node Maintainence of Overload Control State When a reacting node receives an OC-OLR AVP, it MUST determine if it is for an existing or new overload condition. For the remainder of this section the term OLR referres to the combination of the contents of the received OC-OLR AVP and the abatement algorithm indicated in the received OC-Supported- Features AVP. The OLR is for an existing overload condition if the reacting node has an OCS that matches the received OLR. For a host report-type this means it matches the app-id and host-id in an existing host OCS entry. For a realm report-type this means it matches the app-id and realm-id in an existing realm OCS entry. If the OLR is for an existing overload condition then it MUST determine if the OLR is a retransmission or an update to the existing OLR. If the sequence number for the received OLR is greater than the sequence number stored in the matching OCS entry then the reacting node MUST update the matching OCS entry. If the sequence number for the received OLR is less than or equal to the sequence number in the matching OCS entry then the reacting node Korhonen, et al. Expires April 25, 2015 [Page 15] Internet-Draft DOIC October 2014 MUST silently ignore the received OLR. The matching OCS MUST NOT be updated in this case. If the received OLR is for a new overload condition then the reacting node MUST generate a new OCS entry for the overload condition. For a host report-type this means it creates on OCS entry with the app-id of the application-id in the received message and host-id of the Origin-Host in the received message. For a realm report-type this means it creates on OCS entry with the app-id of the application-id in the received message and realm-id of the Origin-Realm in the received message. If the received OLR contains a validity duration of zero ("0") then the reacting node MUST update the OCS entry as being expired. Note that it is not necessarily appropriate to delete the OCS entry, as there is recommended behavior that the reacting node slowly returns to full traffic when ending an overload abatement period. The reacting node does not delete an OCS when receiving an answer message that does not contain an OC-OLR AVP (i.e. absence of OLR means "no change"). 4.2.1.4. Reporting Node Maintainence of Overload Control State A reporting node SHOULD create a new OCS entry when entering an overload condition. If the reporting node knows through absence of the OC-Supported- Features AVP in received messages that there are no reacting nodes supporting DOIC then the reporting node can choose to not create OCS entries. When generating a new OCS entry the sequence nubmer MAY be set to any value if there is no unexpired overload report for previous overload conditions at any reacting node. When generating sequence numbers for new overload conditions, the new sequence number MUST be greater than any sequence number in an active (unexpired) overload report previously sent by the reporting node. This property MUST hold over a reboot of the reporting node. The reporting node MUST update an OCS entry when it needs to adjust the validity duration of the overload contition at reacting nodes. Korhonen, et al. Expires April 25, 2015 [Page 16] Internet-Draft DOIC October 2014 For instance, if the reporting node wishes to instruct reacting nodes to continue overload abatement for a longer period of time that originally communicated. This also applies if the reporting node wishes to shorten the period of time that overload abatement is to continue. A reporting node MUST NOT update the abatement algorithm in an active OCS entry. A reporting node MUST update an OCS entry when it wishes to adjust the any abatement algorithm specific parameters, including the reduction percentage used for the Loss abatement algorithm. For instance, if the reporting node wishes to change the reduction percentage either higher, if the overload condition has worsened, or lower, if the overload condition has improved, then the reporting node would update the appropriate OCS entry. The reporting node MUST update the sequence number associated with the OCS entry anytime the contents of the OCS entry are changed. This will result in a new sequence number being sent to reacting nodes, instructing the reacting nodes to process the OC-OLR AVP. A reporting node SHOULD update an OCS entry with a validity duration of zero ("0") when the overload condition ends. If the reporting node knows that the OCS entries in the reacting nodes are near expiration then the reporting node can decide delete the OCS entry. The reporting node MUST keep an OCS entry with a validity duration of zero ("0") for a period of time long enough to ensure that any reacting node OCS entry created as a result of the overload condition in the reporting node exists. This period of time can be determined by calculating the time the last overload report for the overload condition was sent plus the validity duration included in that overload report. 4.2.2. Reacting Node Behavior When a reacting node sends a request it MUST determine if that request matches an active OCS. If the request matches and active OCS then the reacting number MUST apply abatement treatment on the request. The abatement treatment applied depends on the the abatement algorithm stored in the OCS. Korhonen, et al. Expires April 25, 2015 [Page 17] Internet-Draft DOIC October 2014 For the Loss abatement algorithm defined in this specification, see Section 5 for the abatement logic applied. If the abatement treatment results in throttling of the request and if the reacting node is an agent then the agent MUST send an appropriate error as defined in section Section 7. In the case that the OCS entry validity duration expires or has a validity duration of zero ("0"), meaning that it the reporting node has explicitly signaled the end of the overload condition then abatement associated with the overload abatement MUST be ended in a controlled fashion. 4.2.3. Reporting Node Behavior The operation on the reporting node is straight forward. If there is an active OCS entry then the reporting node SHOULD include the OC-OLR AVP in all answer messages to requests that contain the OC-Supported-Features AVP and that match the active OCS entry. A request matches if the application-id in the request matches the application-id in any active OCS entry and if the report-type in the OCS entry matches a report-type supported by the reporting node as indicated in the OC-Supported-Features AVP. The contents of the OC-OLR AVP MUST contain all information necessary for the abatement algorithm indicated in the OC-Supported-Features message that is also included in the answer message. A reporting node MAY choose to not resend an overload report to a reacting node if it can guarantee that this overload report is already active in the reacting node. Note - In some cases (e.g. when there are one or more agents in the path between reporting and reacting nodes, or when overload reports are discarded by reacting nodes) the reporting node may not be able to guarantee that the reacting node has received the report. A reporting node MUST NOT send overload reports of a type that has not been advertized as supported by the reacting node. Note that a reacting node advertises support for the host and realm report types by including the OC-Supported-Features AVP in the request. Support for other report types must be explicitly indicated by new feature bits in the OC-Feature-Vector AVP. Korhonen, et al. Expires April 25, 2015 [Page 18] Internet-Draft DOIC October 2014 A reporting node MAY rely on the OC-Validity-Duration AVP values for the implicit overload control state cleanup on the reacting node. However, it is RECOMMENDED that the reporting node always explicitly indicates the end of a overload condition. The reporting node SHOULD indicate the end of an overload occurrence by sending a new OLR with OC-Validity-Duration set to a value of zero ("0"). The reporting node SHOULD insure that all reacting nodes receive the updated overload report. All OLRs sent have an expiration time calculated by adding the validity-duration contained in the OLR to the time the message was sent. Transit time for the OLR can be safely ignored. The reporting node can ensure that all reacting nodes have received the OLR by continuing to send it in answer messages until the expiration time for all OLRs sent for that overload contition have expired. When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes. Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the OLR applies. That is, the same candidate set of messages SHOULD NOT be throttled multiple times. However, when the reporting node sends and OLR downstream, it MAY still be responsible to apply other abatement methods, such as diversion, or request throttling requests for other reasons. For example, an agent or server might have a configured rate limit for each client, and throttle requests that exceed that limit, even if such requests had already been candidates for throttling by downstream nodes. This document assumes that there is a single source for realm-reports for a given realm, or that if multiple nodes can send realm reports, that each such node has full knowledge of the overload state of the entire realm. A reacting node cannot distinguish between receiving realm-reports from a single node, or from multiple nodes. If multiple such nodes exist, they MUST ensure that realm-reports are kept in sync. This includes synchronizing the sequence numbers as well as the reported overload state. The method of doing so is up to the implementation. One way to keep the sequence numbers in sync is to generate the sequence numbers based on system time. Editor's Note: There is not yet consensus on the above two paragraphs. Korhonen, et al. Expires April 25, 2015 [Page 19] Internet-Draft DOIC October 2014 --------------050001050707070804040105 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 9 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 9
3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10
3.5. Simplified Example Architecture . . . . . . . . . . . . . 11 3.5. Simplified Example Architecture . . . . . . . . . . . . . 11
4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11
4.1. Capability Announcement . . . . . . . . . . . . . . . . . 12 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 12
4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12
4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12
4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 13 4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 13
4.2. Overload Report Processing . . . . . . . . . . . . . . . 14 4.2. Overload Report Processing . . . . . . . . . . . . . . . 14
4.2.1. Overload Control State . . . . . . . . . . . . . . . 14 4.2.1. Overload Control State . . . . . . . . . . . . . . . 14
4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 17 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 16
4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 18 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 17
4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 20 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 20
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 21 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 21
5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 22 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 22
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 23 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 23
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 23 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 23
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 24 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 24
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 24
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 25 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 25
skipping to change at page 14, line 9 skipping to change at page 14, line 9
If the agent modifies the OC-Supported-Features header sent to the If the agent modifies the OC-Supported-Features header sent to the
reporting node then it might also need to modify the OC-Supported- reporting node then it might also need to modify the OC-Supported-
Features AVP sent to a reacting node in the subsequent answer Features AVP sent to a reacting node in the subsequent answer
message, as it cannot send an indication of support for features message, as it cannot send an indication of support for features
that are not supported by the reacting node. that are not supported by the reacting node.
4.2. Overload Report Processing 4.2. Overload Report Processing
4.2.1. Overload Control State 4.2.1. Overload Control State
Both reacting and reporting nodes maintain Overload Control State Both reacting and reporting nodes maintain an overload control state
(OCS) for active overload conditions. (OCS) for active overload reports.
4.2.1.1. Overload Control State for Reacting Nodes 4.2.1.1. Overload Control State for Reacting Nodes
A reacting node SHOULD maintain the following OCS per supported A reacting node maintains the following OCS per supported Diameter
Diameter application: application:
o A host-type OCS entry for each Destination-Host to which it sends
host-type requests and
o A realm-type OCS entry for each Destination-Realm to which it
sends realm-type requests.
A host-type OCS entry MAY be identified by the pair of Application-Id o A host-type Overload Control State for each Destination-Host
and Host-Id. towards which it sends host-type requests and
A realm-type OCS entry MAY be identified by the pair of Application- o A realm-type Overload Control State for each Destination-Realm
Id and Realm-Id. towards which it sends realm-type requests.
The host-type and realm-type OCS entries MAY include the following A host-type Overload Control State may be identified by the pair of
information (the actual information stored is an implementation Application-Id and Destination-Host. A realm-type Overload Control
decision): State may be identified by the pair of Application-Id and
Destination-Realm. The host-type/realm-type Overload Control State
for a given pair of Application and Destination-Host / Destination-
Realm could include the following information:
o Sequence number (as received in OC-OLR) o Sequence number (as received in OC-OLR)
o Time of expiry (derived from validity duration as received in the o Time of expiry (deviated from validity duration as received in OC-
OC-OLR AVP and time of reception of the message carrying OC-OLR OLR and time of reception)
AVP)
o Selected Abatement Algorithm (as received in OC-Supported-Features o Selected Abatement Algorithm (as received in OC-Supported-
AVP) Features)
o Abatement Algorithm specific input data (as received within the o Algorithm specific input data (as received within OC-OLR, e.g.
OC-OLR AVP, for example, Reduction Percentage for the Loss Reduction Percentage for Loss)
abatement algorithm)
4.2.1.2. Overload Control State for Reporting Nodes 4.2.1.2. Overload Control States for Reporting Nodes
A reporting node SHOULD maintain OCS entries per supported Diameter A reporting node maintains per supported Diameter application and per
application and per supported (and eventually selected) Abatement supported (and eventually selected) Abatement Algorithm an Overload
Algorithm. Control State.
An OCS entry MAY be identified by the pair of Application-Id and An Overload Control State may be identified by the pair of
Abatement Algorithm. Application-Id and supported Abatement Algorithm.
The OCS entry for a given pair of Application and Abatement Algorithm The Overload Control State for a given pair of Application and
MAY include the information (the actual information stored is an Abatement Algorithm could include the information:
implementation decision):
o Report type o Report type
o Sequence number o Sequence number
o Validity Duration o Validity Duration and Expiry Time
o Expiration Time
o Algorithm specific input data (for example, the Reduction
Percentage for the Loss Abatement Algorithm)
4.2.1.3. Reacting Node Maintainence of Overload Control State
When a reacting node receives an OC-OLR AVP, it MUST determine if it
is for an existing or new overload condition.
For the remainder of this section the term OLR referres to the
combination of the contents of the received OC-OLR AVP and the
abatement algorithm indicated in the received OC-Supported-
Features AVP.
The OLR is for an existing overload condition if the reacting node
has an OCS that matches the received OLR.
For a host report-type this means it matches the app-id and host-id
in an existing host OCS entry.
For a realm report-type this means it matches the app-id and realm-id
in an existing realm OCS entry.
If the OLR is for an existing overload condition then it MUST
determine if the OLR is a retransmission or an update to the existing
OLR.
If the sequence number for the received OLR is greater than the
sequence number stored in the matching OCS entry then the reacting
node MUST update the matching OCS entry.
If the sequence number for the received OLR is less than or equal to
the sequence number in the matching OCS entry then the reacting node
MUST silently ignore the received OLR. The matching OCS MUST NOT be
updated in this case.
If the received OLR is for a new overload condition then the reacting
node MUST generate a new OCS entry for the overload condition.
For a host report-type this means it creates on OCS entry with the
app-id of the application-id in the received message and host-id of
the Origin-Host in the received message.
For a realm report-type this means it creates on OCS entry with the
app-id of the application-id in the received message and realm-id of
the Origin-Realm in the received message.
If the received OLR contains a validity duration of zero ("0") then
the reacting node MUST update the OCS entry as being expired.
Note that it is not necessarily appropriate to delete the OCS o Algorithm specific input data (e.g. Reduction Percentage for
entry, as there is recommended behavior that the reacting node Loss)
slowly returns to full traffic when ending an overload abatement
period.
The reacting node does not delete an OCS when receiving an answer 4.2.1.3. Maintaining Overload Control State
message that does not contain an OC-OLR AVP (i.e. absence of OLR
means "no change").
4.2.1.4. Reporting Node Maintainence of Overload Control State Reacting nodes create a host-type OCS identified by OCS-Id = (app-
id,host-id) when receiving an answer message of application app-id
containing an Orig-Host of host-id and a host-type OC-OLR AVP unless
such host-type OCS already exists.
A reporting node SHOULD create a new OCS entry when entering an Reacting nodes create a realm-type OCS identified by OCS-Id = (app-
overload condition. id,realm-id) when receiving an answer message of application app-id
containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP
unless such realm type OCS already exists.
If the reporting node knows through absence of the OC-Supported- Reacting nodes delete an OCS when it expires (i.e. when current time
Features AVP in received messages that there are no reacting nodes minus reception time is greater than validity duration).
supporting DOIC then the reporting node can choose to not create
OCS entries.
When generating a new OCS entry the sequence nubmer MAY be set to any Reacting nodes also delete on OCS with an updated OLR is received
value if there is no unexpired overload report for previous overload with a validity duration of zero.
conditions at any reacting node.
When generating sequence numbers for new overload conditions, the new Reacting nodes update the host-type OCS identified by OCS-Id = (app-
sequence number MUST be greater than any sequence number in an active id,host-id) when receiving an answer message of application app-id
(unexpired) overload report previously sent by the reporting node. containing an Orig-Host of host-id and a host-type OC-OLR AVP with a
This property MUST hold over a reboot of the reporting node. sequence number higher than the stored sequence number.
The reporting node MUST update an OCS entry when it needs to adjust Reacting nodes update the realm-type OCS identified by OCS-Id = (app-
the validity duration of the overload contition at reacting nodes. id,realm-id) when receiving an answer message of application app-id
containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP with
a sequence number higher than the stored sequence number.
For instance, if the reporting node wishes to instruct reacting Reacting nodes do not delete an OCS when receiving an answer message
nodes to continue overload abatement for a longer period of time that does not contain an OC-OLR AVP (i.e. absence of OLR means "no
that originally communicated. This also applies if the reporting change").
node wishes to shorten the period of time that overload abatement
is to continue.
A reporting node MUST NOT update the abatement algorithm in an active Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg)
OCS entry. when receiving a request of application app-id containing an OC-
Supported-Features AVP indicating support of the Abatement Algorithm
Alg (which the reporting node selects) while being overloaded, unless
such OCS already exists.
A reporting node MUST update an OCS entry when it wishes to adjust Reporting nodes delete an OCS when it expires.
the any abatement algorithm specific parameters, including the
reduction percentage used for the Loss abatement algorithm.
For instance, if the reporting node wishes to change the reduction Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg)
percentage either higher, if the overload condition has worsened, when they detect the need to modify the requested amount of
or lower, if the overload condition has improved, then the application app-id traffic reduction.
reporting node would update the appropriate OCS entry.
The reporting node MUST update the sequence number associated with 4.2.2. Reacting Node Behavior
the OCS entry anytime the contents of the OCS entry are changed.
This will result in a new sequence number being sent to reacting
nodes, instructing the reacting nodes to process the OC-OLR AVP.
A reporting node SHOULD update an OCS entry with a validity duration Once a reacting node receives an OC-OLR AVP from a reporting node, it
of zero ("0") when the overload condition ends. applies traffic abatement based on the selected algorithm with the
reporting node and the current overload condition. The reacting node
learns the reporting node supported abatement algorithms directly
from the received answer message containing the OC-Supported-Features
AVP.
If the reporting node knows that the OCS entries in the reacting The received OC-Supported-Features AVP does not change the existing
nodes are near expiration then the reporting node can decide overload condition and/or traffic abatement algorithm settings if the
delete the OCS entry. OC-Sequence-Number AVP contains a value that is equal to the
previously received/recorded value. If the OC-Supported-Features AVP
is received for the first time for the reporting node or the OC-
Sequence-Number AVP value is less than the previously received/
recorded value (and is outside the valid overflow window), then the
sequence number is stale (e.g. an intentional or unintentional
replay) and SHOULD be silently discarded.
The reporting node MUST keep an OCS entry with a validity duration of As described in Section 6.3, the OC-OLR AVP contains the necessary
zero ("0") for a period of time long enough to ensure that any information for the overload condition on the reporting node.
reacting node OCS entry created as a result of the overload condition
in the reporting node exists.
This period of time can be determined by calculating the time the From the OC-Report-Type AVP contained in the OC-OLR AVP, the reacting
last overload report for the overload condition was sent plus the node learns whether the overload condition report concerns a specific
validity duration included in that overload report. host (as identified by the Origin-Host AVP of the answer message
containing the OC-OLR AVP) or the entire realm (as identified by the
Origin-Realm AVP of the answer message containing the OC-OLR AVP).
The reacting node learns the Diameter application to which the
overload report applies from the Application-ID of the answer message
containing the OC-OLR AVP. The reacting node MUST use this
information as an input for its traffic abatement algorithm. The
idea is that the reacting node applies different handling of the
traffic abatement, whether sent request messages are targeted to a
specific host (identified by the Diameter-Host AVP in the request) or
to any host in a realm (when only the Destination-Realm AVP is
present in the request). Note that future specifications MAY define
new OC-Report-Type AVP values that imply different handling of the
OC-OLR AVP. For example, in a form of new additional AVPs inside the
Grouped OC-OLR AVP that would define report target in a finer
granularity than just a host.
4.2.2. Reacting Node Behavior If the OC-OLR AVP is received for the first time, the reacting node
MUST create overload control state associated with the related realm
or a specific host in the realm identified in the message carrying
the OC-OLR AVP, as described in Section 4.2.1.
When a reacting node sends a request it MUST determine if that If the value of the OC-Sequence-Number AVP contained in the received
request matches an active OCS. OC-OLR AVP is equal to or less than the value stored in an existing
overload control state, the received OC-OLR AVP SHOULD be silently
discarded. If the value of the OC-Sequence-Number AVP contained in
the received OC-OLR AVP is greater than the value stored in an
existing overload control state or there is no previously recorded
sequence number, the reacting node MUST update the overload control
state associated with the realm or the specific node in the realm.
If the request matches and active OCS then the reacting number MUST When an overload control state is created or updated, the reacting
apply abatement treatment on the request. The abatement treatment node MUST apply the traffic abatement requested in the OC-OLR AVP
applied depends on the the abatement algorithm stored in the OCS. using the algorithm announced in the OC-Supported-Features AVP
contained in the received answer message along with the OC-OLR AVP.
For the Loss abatement algorithm defined in this specification, see The validity duration of the overload information contained in the
Section 5 for the abatement logic applied. OC-OLR AVP is either explicitly indicated in the OC-Validity-Duration
AVP or is implicitly equals to the default value if the OC-Validity-
Duration AVP is absent. The reacting node MUST maintain the validity
duration in the overload control state. Once the validity duration
times out, the reacting node MUST assume the overload condition
reported in a previous OC-OLR AVP has ended.
If the abatement treatment results in throttling of the request and A value of zero ("0") received in the OC-Validity-Duration in an
if the reacting node is an agent then the agent MUST send an updated overload report indicates that the overload condition has
appropriate error as defined in section Section 7. ended and that the overload state is no longer valid.
In the case that the OCS entry validity duration expires or has a In the case that the validity duration expires or is explicitly
validity duration of zero ("0"), meaning that it the reporting node signaled as being no longer valid the state associated with the
has explicitly signaled the end of the overload condition then overload report MUST be removed and any abatement associated with the
abatement associated with the overload abatement MUST be ended in a overload report MUST be ended in a controlled fashion. After
controlled fashion. removing the overload state the sequence number MUST NOT be used for
future comparisons of sequence numbers.
4.2.3. Reporting Node Behavior 4.2.3. Reporting Node Behavior
The operation on the reporting node is straight forward. A reporting node is a Diameter node inserting an OC-OLR AVP in a
Diameter message in order to inform a reacting node about an overload
If there is an active OCS entry then the reporting node SHOULD condition and request Diameter traffic abatement.
include the OC-OLR AVP in all answer messages to requests that
contain the OC-Supported-Features AVP and that match the active OCS
entry.
A request matches if the application-id in the request matches the The operation on the reporting node is straight forward. The
application-id in any active OCS entry and if the report-type in reporting node learns the capabilities of the reacting node when it
the OCS entry matches a report-type supported by the reporting receives the OC-Supported-Features AVP as part of any Diameter
node as indicated in the OC-Supported-Features AVP. request message. Since the loss abatement algorithm Section 5 is
mandatory to implement DOIC can always be enabled between these DOIC
nodes See Section 4.1 for further discussion on the capability and
feature announcement.
The contents of the OC-OLR AVP MUST contain all information necessary When a traffic reduction is required due to an overload condition and
for the abatement algorithm indicated in the OC-Supported-Features the overload control solution is supported by the sender of the
message that is also included in the answer message. Diameter request, the reporting node SHOULD include an OC-Supported-
Features AVP and an OC-OLR AVP in the corresponding Diameter answer.
A reporting node MAY choose to not resend an overload report to a A reporting node MAY choose to not resend an overload report to a
reacting node if it can guarantee that this overload report is reacting node if it can guarantee that this overload report is
already active in the reacting node. already active in the reacting node.
Note - In some cases (e.g. when there are one or more agents in Note - In some cases (e.g. when there are one or multiple agents
the path between reporting and reacting nodes, or when overload in the path between reporting and reacting nodes, or when overload
reports are discarded by reacting nodes) the reporting node may reports are discarded by reacting nodes) the reporting node may
not be able to guarantee that the reacting node has received the not be able to guarantee that the reacting node has received the
report. report.
The OC-OLR AVP contains the required traffic reduction and the OC-
Supported-Features AVP indicates the traffic abatement algorithm to
apply. This algorithm MUST be one of the algorithms advertised by
the request sender.
A reporting node MUST NOT send overload reports of a type that has A reporting node MUST NOT send overload reports of a type that has
not been advertized as supported by the reacting node. not been advertized as supported by the reacting node.
Note that a reacting node advertises support for the host and Note that a reacting node advertises support for the host and
realm report types by including the OC-Supported-Features AVP in realm report types by including the OC-Supported-Features AVP in
the request. Support for other report types must be explicitly the request. Support for other report types must be explicitly
indicated by new feature bits in the OC-Feature-Vector AVP. indicated by a new feature bit in the OC-Feature-Vector AVP.
If OLR is for a new overload condition and there is no unexpired
overload report for previous overload conditions at any reacting node
then the reporting node MAY set the sequence number to any value.
The reporting node MAY update the overload report with new reduction
percentages.
The reporting node MAY extend the validatity duration for an existing
overload report by sending a OLR with either the same or a new
validity duration value.
When sending an overload report with new values in any of the sub
AVPs for an existing overload condition, the reporting node MUST
increase the sequence number in the new OLR sent.
When generating sequence numbers for new overload conditions, the new
sequence number MUST be greater than any sequence number in an active
(unexpired) overload report previously sent by the reporting node.
This property MUST hold over a reboot of the reporting node.
A reporting node MAY rely on the OC-Validity-Duration AVP values for A reporting node MAY rely on the OC-Validity-Duration AVP values for
the implicit overload control state cleanup on the reacting node. the implicit overload control state cleanup on the reacting node.
However, it is RECOMMENDED that the reporting node always explicitly However, it is RECOMMENDED that the reporting node always explicitly
indicates the end of a overload condition. indicates the end of a overload condition.
The reporting node SHOULD indicate the end of an overload occurrence The reporting node SHOULD indicate the end of an overload occurrence
by sending a new OLR with OC-Validity-Duration set to a value of zero by sending a new OLR with OC-Validity-Duration set to a value of zero
("0"). The reporting node SHOULD insure that all reacting nodes ("0"). The reporting node SHOULD insure that all reacting nodes
receive the updated overload report. receive the updated overload report.
All OLRs sent have an expiration time calculated by adding the
validity-duration contained in the OLR to the time the message was
sent. Transit time for the OLR can be safely ignored. The
reporting node can ensure that all reacting nodes have received
the OLR by continuing to send it in answer messages until the
expiration time for all OLRs sent for that overload contition have
expired.
When a reporting node sends an OLR, it effectively delegates any When a reporting node sends an OLR, it effectively delegates any
necessary throttling to downstream nodes. Therefore, the reporting necessary throttling to downstream nodes. Therefore, the reporting
node SHOULD NOT apply throttling to the set of messages to which the node SHOULD NOT apply throttling to the set of messages to which the
OLR applies. That is, the same candidate set of messages SHOULD NOT OLR applies. That is, the same candidate set of messages SHOULD NOT
be throttled multiple times. be throttled multiple times.
However, when the reporting node sends and OLR downstream, it MAY However, when the reporting node sends and OLR downstream, it MAY
still be responsible to apply other abatement methods, such as still be responsible to apply other abatement methods, such as
diversion, or request throttling requests for other reasons. For diversion, or request throttling requests for other reasons. For
example, an agent or server might have a configured rate limit for example, an agent or server might have a configured rate limit for
each client, and throttle requests that exceed that limit, even if each client, and throttle requests that exceed that limit, even if
such requests had already been candidates for throttling by such requests had already been candidates for throttling by
downstream nodes. downstream nodes.
All OLRs sent have an expiration time calculated by adding the
validity-duration contained in the OLR to the time the message was
sent. Transit time for the OLR can be safely ignored. The
reporting node can ensure that all reacting nodes have received
the OLR by continuing to send it in answer messages until the
expiration time for all OLRs sent for that overload contition have
expired.
This document assumes that there is a single source for realm-reports This document assumes that there is a single source for realm-reports
for a given realm, or that if multiple nodes can send realm reports, for a given realm, or that if multiple nodes can send realm reports,
that each such node has full knowledge of the overload state of the that each such node has full knowledge of the overload state of the
entire realm. A reacting node cannot distinguish between receiving entire realm. A reacting node cannot distinguish between receiving
realm-reports from a single node, or from multiple nodes. realm-reports from a single node, or from multiple nodes.
If multiple such nodes exist, they MUST ensure that realm-reports are If multiple such nodes exist, they MUST ensure that realm-reports are
kept in sync. This includes synchronizing the sequence numbers as kept in sync. This includes synchronizing the sequence numbers as
well as the reported overload state. The method of doing so is up to well as the reported overload state. The method of doing so is up to
the implementation. One way to keep the sequence numbers in sync is the implementation. One way to keep the sequence numbers in sync is
to generate the sequence numbers based on system time. to generate the sequence numbers based on system time.
Editor's Note: There is not yet consensus on the above two
paragraphs.
4.3. Protocol Extensibility 4.3. Protocol Extensibility
The overload control solution can be extended, e.g. with new traffic The overload control solution can be extended, e.g. with new traffic
abatement algorithms, new report types or other new functionality. abatement algorithms, new report types or other new functionality.
When defining a new extension a new feature bit MUST be defined for When defining a new extension a new feature bit MUST be defined for
the OC-Feature-Vector. This feature bit is used to communicate the OC-Feature-Vector. This feature bit is used to communicate
support for the new feature. support for the new feature.
The extention MAY define new AVPs for use in DOIC Capability The extention MAY define new AVPs for use in DOIC Capability
 End of changes. 46 change blocks. 
184 lines changed or deleted 184 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------050001050707070804040105-- From nobody Wed Oct 22 09:36:06 2014 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 1A14A1ACD26 for ; Wed, 22 Oct 2014 08:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 sRF5JVXP0ky5 for ; Wed, 22 Oct 2014 08:08:56 -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 AD1B81ACD12 for ; Wed, 22 Oct 2014 08:08:12 -0700 (PDT) Received: from 187.31.0.109.rev.sfr.net ([109.0.31.187]:55392 helo=b8e856229362.netpoint.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XgxWE-0003yr-0n for dime@ietf.org; Wed, 22 Oct 2014 08:08:11 -0700 Message-ID: <5447C858.806@usdonovans.com> Date: Wed, 22 Oct 2014 17:08:08 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/mixed; boundary="------------080705080607070801010908" 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4YdGKWbXEqiLfMZ_a2sI2xmLKRs X-Mailman-Approved-At: Wed, 22 Oct 2014 09:36:01 -0700 Subject: [Dime] Update based on comments received from Benoit, Jouni and Maria Cruz 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, 22 Oct 2014 15:09:08 -0000 This is a multi-part message in MIME format. --------------080705080607070801010908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One final update for today. I have updated github with changes based on primarily editorial comments from Benoit, Jouni and Maria Cruz. Many of the suggestions had already been addressed or were made irrelevant by previous changes. I have attached the diff file to this message. Regards, Steve --------------080705080607070801010908 Content-Type: text/html; charset=ISO-8859-1; name="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04."; filename*1="txt.html" Diff: draft-ietf-dime-ovli-04.txt - draft-ietf-dime-ovli-04.txt
< draft-ietf-dime-ovli-04.txt   draft-ietf-dime-ovli-04.txt >
skipping to change at page 2, line 22 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 7 3.1. Piggybacking Principle . . . . . . . . . . . . . . . . . 7
3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 8 3.2. DOIC Capability Announcement . . . . . . . . . . . . . . 8
3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 9 3.3. DOIC Overload Condition Reporting . . . . . . . . . . . . 9
3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10 3.4. DOIC Extensibility . . . . . . . . . . . . . . . . . . . 10
3.5. Simplified Example Architecture . . . . . . . . . . . . . 11 3.5. Simplified Example Architecture . . . . . . . . . . . . . 11
4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 12 4. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 11
4.1. Capability Announcement . . . . . . . . . . . . . . . . . 12 4.1. Capability Announcement . . . . . . . . . . . . . . . . . 12
4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12 4.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 12
4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12 4.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 12
4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 13 4.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 13
4.2. Overload Report Processing . . . . . . . . . . . . . . . 14 4.2. Overload Report Processing . . . . . . . . . . . . . . . 14
4.2.1. Overload Control State . . . . . . . . . . . . . . . 14 4.2.1. Overload Control State . . . . . . . . . . . . . . . 14
4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 18 4.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 17
4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 18 4.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 18
4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 20 4.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 20
5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 21 5. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 22 5.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 21
5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 22 5.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 22
6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 23 6. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 23
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 23 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 23
6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 24 6.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 24
6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 24
6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 25 6.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 25
6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 25 6.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 25
6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 26 6.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 26
6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 27 6.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 27
6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27 6.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27
skipping to change at page 3, line 27 skipping to change at page 3, line 27
Solution . . . . . . . . . . . . . . . . . . . . . . 35 Solution . . . . . . . . . . . . . . . . . . . . . . 35
C.1. Application Classification . . . . . . . . . . . . . . . 35 C.1. Application Classification . . . . . . . . . . . . . . . 35
C.2. Application Type Overload Implications . . . . . . . . . 36 C.2. Application Type Overload Implications . . . . . . . . . 36
C.3. Request Transaction Classification . . . . . . . . . . . 37 C.3. Request Transaction Classification . . . . . . . . . . . 37
C.4. Request Type Overload Implications . . . . . . . . . . . 38 C.4. Request Type Overload Implications . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
This specification defines a base solution for Diameter Overload This specification defines a base solution for Diameter Overload
Control (DOC), referred to as Diameter Overload Indication Conveyance Control (DOC), refered to as Diameter Overload Indication Conveyance
(DOIC). The requirements for the solution are described and (DOIC). The requirements for the solution are described and
discussed in the corresponding design requirements document discussed in the corresponding design requirements document
[RFC7068]. Note that the overload control solution defined in this [RFC7068]. Note that the overload control solution defined in this
specification does not address all the requirements listed in specification does not address all the requirements listed in
[RFC7068]. A number of overload control related features are left [RFC7068]. A number of overload control related features are left
for the future specifications. See Appendix A for a list of for the future specifications. See Appendix A for a list of
extensions that are currently being considered. See Appendix A.3 for extensions that are currently being considered. See Appendix A.3 for
an analysis of the conformance to the requirements specified in an analysis of the conformance to the requirements specified in
[RFC7068]. [RFC7068].
The solution defined in this specification addresses Diameter The solution defined in this specification addresses Diameter
overload control between Diameter nodes that support the DOIC overload control between Diameter nodes that support the DOIC
solution. Furthermore, the solution which is designed to apply to solution. Furthermore, the solution is designed to apply to existing
existing and future Diameter applications, requires no changes to the and future Diameter applications, requires no changes to the Diameter
Diameter base protocol [RFC6733] and is deployable in environments base protocol [RFC6733] and is deployable in environments where some
where some Diameter nodes do not implement the Diameter overload Diameter nodes do not implement the Diameter overload control
control solution defined in this specification. solution defined in this specification.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
Abatement Abatement
Reaction to receipt of an overload report resulting in a reduction Reaction to receipt of an overload report resulting in a reduction
in traffic sent to the reporting node. Abatement actions include in traffic sent to the reporting node. Abatement actions include
diversion and throttling. diversion and throttling.
Abatement Algorithm Abatement Algorithm
An mechanism requested by reporting nodes and used by reacting An algorithm requested by reporting nodes and used by reacting
nodes to reduce the amount of traffic sent during an occurrence of nodes to reduce the amount of traffic sent during an occurrence of
overload control. overload control.
Diversion Diversion
Abatement of traffic sent to a reporting node by a reacting node Abatement of traffic sent to a reporting node by a reacting node
in response to receipt of an overload report. The abatement is in response to receipt of an overload report. The abatement is
achieved by diverting traffic from the reporting node to another achieved by diverting traffic from the reporting node to another
Diameter node that is able to process the request. Diameter node that is able to process the request.
Host-Routed Request Host-Routed Request
The set of requests that a reacting node knows will be served by a The set of requests that a reacting node knows will be served by a
particular host, either due to the presence of a Destination-Host particular host, either due to the presence of a Destination-Host
AVP, or by some other local knowledge on the part of the reacting AVP, or by some other local knowledge on the part of the reacting
node. node.
Overload Control State (OCS) Overload Control State (OCS)
Reporting and reacting node internally maintained state describing State describing an occurrence of overload control maintained by
occurrences of overload control. reporting and reacting nodes.
Overload Report (OLR) Overload Report (OLR)
Information sent by a reporting node indicating the start or A set of AVPs sent by a reporting node indicating the start or
continuation of an occurrence of overload control. continuation of an occurrence of overload control.
Reacting Node Reacting Node
A Diameter node that acts upon an overload report. A Diameter node that consumes and acts upon a report.
Realm-Routed Request Realm-Routed Request
The set of requests that a reacting node does not know the host The set of requests that a reacting node does not know the host
that will service the request. that will service the request.
Reporting Node Reporting Node
A Diameter node that generates an overload report. (This may or A Diameter node that generates an overload report. (This may or
may not be the overloaded node.) may not be the overloaded node.)
skipping to change at page 5, line 27 skipping to change at page 5, line 27
Diameter nodes to request other nodes to perform overload abatement Diameter nodes to request other nodes to perform overload abatement
actions, that is, actions to reduce the load offered to the actions, that is, actions to reduce the load offered to the
overloaded node or realm. overloaded node or realm.
A Diameter node that supports DOIC is known as a "DOIC node". Any A Diameter node that supports DOIC is known as a "DOIC node". Any
Diameter node can act as a DOIC node, including clients, servers, and Diameter node can act as a DOIC node, including clients, servers, and
agents. DOIC nodes are further divided into "Reporting Nodes" and agents. DOIC nodes are further divided into "Reporting Nodes" and
"Reacting Nodes." A reporting node requests overload abatement by "Reacting Nodes." A reporting node requests overload abatement by
sending an Overload Report (OLR) to one or more reacting nodes. sending an Overload Report (OLR) to one or more reacting nodes.
A reacting node acts upon OLRs, and performs whatever actions are A reacting node consumes OLRs, and performs whatever actions are
needed to fulfil the abatement requests included in the OLRs. A needed to fulfill the abatement requests included in the OLRs. A
Reporting node may report overload on its own behalf, or on behalf of Reporting node may report overload on its own behalf, or on behalf of
other (typically upstream) nodes. Likewise, a reacting node may other (typically upstream) nodes. Likewise, a reacting node may
perform overload abatement on its own behalf, or on behalf of other perform overload abatement on its own behalf, or on behalf of other
(typically downstream) nodes. (typically downstream) nodes.
A node's role as a DOIC node is independent of its Diameter role. A node's role as a DOIC node is independent of its Diameter role.
For example, Diameter Relay and Proxy Agents may act as DOIC nodes, For example, Diameter Relay and Proxy Agents may act as DOIC nodes,
even though they are not endpoints in the Diameter sense. Since even though they are not endpoints in the Diameter sense. Since
Diameter enables bi-directional applications, where Diameter Servers Diameter enables bi-directional applications, where Diameter Servers
can send requests towards Diameter Clients, a given Diameter node can can send requests towards Diameter Clients, a given Diameter node can
skipping to change at page 6, line 10 skipping to change at page 6, line 10
information. Rather, they "piggyback" DOIC information over existing information. Rather, they "piggyback" DOIC information over existing
Diameter messages by inserting new AVPs into existing Diameter Diameter messages by inserting new AVPs into existing Diameter
requests and responses. Nodes indicate support for DOIC, and any requests and responses. Nodes indicate support for DOIC, and any
needed DOIC parameters by inserting an OC_Supported_Features AVP needed DOIC parameters by inserting an OC_Supported_Features AVP
(Section 6.2) into existing requests and responses. Reporting nodes (Section 6.2) into existing requests and responses. Reporting nodes
send OLRs by inserting OC-OLR AVPs (Section 6.3). send OLRs by inserting OC-OLR AVPs (Section 6.3).
A given OLR applies to the Diameter realm and application of the A given OLR applies to the Diameter realm and application of the
Diameter message that carries it. If a reporting node supports more Diameter message that carries it. If a reporting node supports more
than one realm and/or application, it reports independently for each than one realm and/or application, it reports independently for each
combination of realm and application. Similarly, the OC-Supported- combination of realm and application. Similarly, OC-Feature-Vector
Features AVP applies to the realm and application of the enclosing AVPs apply to the realm and application of the enclosing message.
message. This implies that a node may support DOIC for one This implies that a node may support DOIC for one application and/or
application and/or realm, but not another, and may indicate different realm, but not another, and may indicate different DOIC parameters
DOIC parameters for each application and realm for which it supports for each application and realm for which it supports DOIC.
DOIC.
Reacting nodes perform overload abatement according to an agreed-upon Reacting nodes perform overload abatement according to an agreed-upon
abatement algorithm. An abatement algorithm defines the meaning of abatement algorithm. An abatement algorithm defines the meaning of
the parameters of an OLR and the procedures required for overload the parameters of an OLR, and the procedures required for overload
abatement. This document specifies a single must-support algorithm, abatement. This document specifies a single must-support algorithm,
namely the "loss" algorithm (Section 5). Future specifications may namely the "loss" algorithm (Section 5). Future specifications may
introduce new algorithms. introduce new algorithms.
Overload conditions may vary in scope. For example, a single Overload conditions may vary in scope. For example, a single
Diameter node may be overloaded, in which case reacting nodes may Diameter node may be overloaded, in which case reacting nodes may
reasonably attempt to send requests to other destinations or via reasonably attempt to send throttled requests to other destinations
other agents. On the other hand, an entire Diameter realm may be or via other agents. On the other hand, an entire Diameter realm may
overloaded, in which case such attempts would do harm. DOIC OLRs be overloaded, in which case such attempts would do harm. DOIC OLRs
have a concept of "report type" (Section 6.6), where the type defines have a concept of "report type" (Section 6.6), where the type defines
such behaviors. Report types are extensible. This document defines such behaviors. Report types are extensible. This document defines
report types for overload of a specific server, and for overload of report types for overload of a specific server, and for overload of
an entire realm. an entire realm.
A report of type host is sent to indicate the overload of a specific A report of type host is sent to indicate the overload of a specific
server for the application-id indicated in the transaction. When server for the application-id indicated in the transaction. When
receiving an OLR of type host, a reacting node applies overload receiving an OLR of type host, a reacting node applies overload
abatement to what is referred to in this document as host-routed abatement to what is referred to in this document as host-routed
requests. This is the set of requests that the reacting node knows requests. This is the set of requests that the reacting node knows
skipping to change at page 7, line 28 skipping to change at page 7, line 28
The overload control AVPs defined in this specification have been The overload control AVPs defined in this specification have been
designed to be piggybacked on top of existing application messages. designed to be piggybacked on top of existing application messages.
This is made possible by adding overload control top-level AVPs, the This is made possible by adding overload control top-level AVPs, the
OC-OLR AVP and the OC-Supported-Features AVP, as optional AVPs into OC-OLR AVP and the OC-Supported-Features AVP, as optional AVPs into
existing commands when the corresponding Command Code Format (CCF) existing commands when the corresponding Command Code Format (CCF)
specification allows adding new optional AVPs (see Section 1.3.4 of specification allows adding new optional AVPs (see Section 1.3.4 of
[RFC6733]). [RFC6733]).
Reacting nodes indicate support for DOIC by including the OC- Reacting nodes indicate support for DOIC by including the OC-
Supported-Features AVP in all request messages originated or relayed Supported-Features AVP in all request messages originated or relayed
by the reacting node. by the Diameter node.
Reporting nodes indicate support for DOIC by including the OC- Reporting nodes indicate support for DOIC by including the OC-
Supported-Features AVP in all answer messages originated or relayed Supported-Features AVP in all answer messages originated or relayed
by the reporting node. Reporting nodes also include overload reports by the Diameter node. Reporting nodes also include overload reports
using the OC-OLR AVP in answer messages. using the OC-OLR AVP in answer messages.
Note: There is no new Diameter application defined to carry Note: There is no new Diameter application defined to carry
overload related AVPs. The DOIC AVPs are carried in existing overload related AVPs. The DOIC AVPs are carried in existing
Diameter application messages. Diameter application messages.
Note that the overload control solution does not have fixed server Note that the overload control solution does not have fixed server
and client roles. The DOIC node role is determined based on the and client roles. The DOIC node role is determined based on the
message type: whether the message is a request (i.e. sent by a message type: whether the message is a request (i.e. sent by a
"reacting node") or an answer (i.e. send by a "reporting node"). "reacting node") or an answer (i.e. send by a "reporting node").
skipping to change at page 8, line 12 skipping to change at page 8, line 12
is the Diameter Server requesting a re-authentication from a Diameter is the Diameter Server requesting a re-authentication from a Diameter
Client. Client.
3.2. DOIC Capability Announcement 3.2. DOIC Capability Announcement
The DOIC solution supports the ability for Diameter nodes to The DOIC solution supports the ability for Diameter nodes to
determine if other nodes in the path of a request support the determine if other nodes in the path of a request support the
solution. This capability is referred to as DOIC Capability solution. This capability is referred to as DOIC Capability
Announcement (DCA) and is separate from Diameter Capability Exchange. Announcement (DCA) and is separate from Diameter Capability Exchange.
The DCA solution uses the OC-Supported-Features AVPs to indicate the The DCA mechanism uses the OC-Supported-Features AVPs to indicate the
Diameter overload features supported. Diameter overload features supported.
The first node in the path of a Diameter request that supports the The first node in the path of a Diameter request that supports the
DOIC solution inserts the OC-Supported-Feature AVP in the request DOIC solution inserts the OC-Supported-Feature AVP in the request
message. This includes an indication that it supports the loss message. This includes an indication that it supports the loss
overload abatement algorithm defined in this specification (see overload abatement algorithm defined in this specification (see
Section 5). This insures that there is at least one commonly Section 5). This insures that there is at least one commonly
supported overload abatement algorithm between the reporting node and supported overload abatement algorithm between the reporting node and
the reacting nodes in the path of the request. the reacting nodes in the path of the request.
DOIC must support deployments where Diameter Clients and/or DOIC must support deployments where Diameter Clients and/or
Diameter Servers do not support the DOIC solution. In this Diameter servers do not support the DOIC solution. In this
scenario, it is assumed that Diameter Agents that support the DOIC scenario, it is assumed that Diameter Agents that support the DOIC
solution will handle overload abatement for the non supporting solution will handle overload abatement for the non supporting
Diameter nodes. In this case the DOIC agent will insert the OC- clients. In this case the DOIC agent will insert the OC-
Supporting-Features AVP in requests that do not already contain Supporting-Features AVP in requests that do not already contain
one, telling the reporting node that there is a DOIC node that one, telling the reporting node that there is a DOIC node that
will handle overload abatement. will handle overload abatement.
The reporting node inserts the OC-Supported-Feature AVP in all answer The reporting node inserts the OC-Supported-Feature AVP in all answer
messages to requests that contained the OC-Supported-Feature AVP. messages to requests that contained the OC-Supported-Feature AVP.
The contents of the reporting node's OC-Supported-Feature AVP The contents of the reporting node's OC-Supported-Feature AVP
indicate the set of Diameter overload features supported by the indicate the set of Diameter overload features supported by the
reporting node with one exception. reporting node with one exception.
The reporting node only includes an indication of support for one The reporting node only includes an indication of support for one
overload abatement algorithm. This is the algorithm that the overload abatement algorithm. This is the algorithm that the
reporting node intends to use should it enter an overload condition reporting node intends to use should it enter an overload condition.
or requests to use while it actually is in an overload condition.
Reacting nodes can use the indicated overload abatement algorithm to Reacting nodes can use the indicated overload abatement algorithm to
prepare for possible overload reports and must use the indicated prepare for possible overload reports.
overload abatement algorithm if traffic reduction is actually
requested.
Note that the loss algorithm defined in this document is a Note that the loss algorithm defined in this document is a
stateless abatement algorithm. As a result it does not require stateless abatement algorithm. As a result it does not require
any actions by reacting nodes prior to the receipt of an overload any actions by reacting nodes prior to the receipt of an overload
report. Stateful abatement algorithms that base the abatement report. Stateful abatement algorithms that base the abatement
logic on a history of request messages sent might require reacting logic on a history of request messages sent might require reacting
nodes to maintain state to insure that overload reports can be nodes to maintain state to insure that overload reports can be
properly handled. properly handled.
The individual features supported by the DOIC nodes are indicated in The individual features supported by the DOIC nodes are indicated in
skipping to change at page 9, line 35 skipping to change at page 9, line 33
As with DOIC Capability Announcement, Overload Condition Reporting As with DOIC Capability Announcement, Overload Condition Reporting
uses new AVPs (Section 6.3) to indicate an overload condition. uses new AVPs (Section 6.3) to indicate an overload condition.
The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP
includes the type of report, a sequence number, the length of time includes the type of report, a sequence number, the length of time
that the report is valid and abatement algorithm specific AVPs. that the report is valid and abatement algorithm specific AVPs.
Two types of overload reports are defined in this document, host Two types of overload reports are defined in this document, host
reports and realm reports. reports and realm reports.
A report of type host is sent to indicate the overload of a specific Host reports apply to traffic that is sent to a specific Diameter
Diameter node for the application-id indicated in the transaction. host. The applies to requests that contain the Destination-Host AVP
When receiving an OLR of type host, a reacting node applies overload that contains a DiameterIdentity that matches that of the overload
abatement to what is referred to in this document as host-routed report. These requests are referred to as host-routed requests. A
requests. This is the set of requests that the reacting node knows host report also applies to requests that do not have a Destination-
will be served by a particular host, either due to the presence of a Host AVP when the selected route for the request is a connection to
Destination-Host AVP, or by some other local knowledge on the part of the impacted host.
the reacting node. The reacting node applies overload abatement on
those host-routed requests which the reacting node knows will be
served by the server that matches the Origin-Host AVP of the received
message that contained the received OLR of type host.
Realm reports apply to realm-routed requests for a specific realm as Realm reports apply to realm-routed requests for a specific realm as
indicated in the Destination-Realm AVP. indicated in the Destination-Realm AVP.
Reporting nodes are responsible for determining the need for a Reporting nodes are responsible for determining the need for a
reduction of traffic. The method for making this determination is reduction of traffic. The method for making this determination is
implementation specific and depend on the type of overload report implementation specific and depend on the type of overload report
being generated. A host report, for instance, will generally be being generated. A host report, for instance, will generally be
generated by tracking utilization of resources required by the host generated by tracking utilization of resources required by the host
to handle transactions for the Diameter application. A realm report to handle transactions for the Diameter application. A realm report
skipping to change at page 10, line 35 skipping to change at page 10, line 28
in extensions to the DOIC solutions. in extensions to the DOIC solutions.
As the conditions that lead to the generation of the overload report As the conditions that lead to the generation of the overload report
change the reporting node can send new overload reports requesting change the reporting node can send new overload reports requesting
greater reduction if the condition gets worse or less reduction if greater reduction if the condition gets worse or less reduction if
the condition improves. The reporting node sends an overload report the condition improves. The reporting node sends an overload report
with a duration of zero to indicate that the overload condition has with a duration of zero to indicate that the overload condition has
ended and use of the abatement algorithm is no longer needed. ended and use of the abatement algorithm is no longer needed.
The reacting node also determines when the overload report expires The reacting node also determines when the overload report expires
based on the OC-Validity-Duration AVP in the overload report and based on the OC-Validaty-Duration AVP in the overload report and
stops applying the abatement algorithm when the report expires. stops applying the abatement algorithm when the report expires.
3.4. DOIC Extensibility 3.4. DOIC Extensibility
The DOIC solution is designed to be extensible. This extensibility The DOIC solution is designed to be extensible. This extensibility
is based on existing Diameter based extensibility mechanisms. is based on existing Diameter based extensibility mechanisms.
There are multiple categories of extensions that are expected. This There are multiple categories of extensions that are expected. This
includes the definition of new overload abatement algorithms, the includes the definition of new overload abatement algorithms, the
definition of new report types and new definitions of the scope of definition of new report types and new definitions of the scope of
skipping to change at page 11, line 4 skipping to change at page 10, line 45
There are multiple categories of extensions that are expected. This There are multiple categories of extensions that are expected. This
includes the definition of new overload abatement algorithms, the includes the definition of new overload abatement algorithms, the
definition of new report types and new definitions of the scope of definition of new report types and new definitions of the scope of
messages impacted by an overload report. messages impacted by an overload report.
The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes
to communicate supported features. The specific features supported to communicate supported features. The specific features supported
by the DOIC node are indicated in the OC-Feature-Vector AVP. DOIC by the DOIC node are indicated in the OC-Feature-Vector AVP. DOIC
extensions must define new values for the OC-Feature-Vector AVP. extensions must define new values for the OC-Feature-Vector AVP.
DOIC extensions also have the ability to add new AVPs to the OC- DOIC extensions also have the ability to add new AVPs to the OC-
Supported-Features AVP, if additional information about the new Supported-Features AVP, if additional information about the new
feature is required. feature is required.
Reporting nodes use the OC-OLR AVP to communicate overload Overload abatement algorithms use the OC-OLR AVP to communicate
occurrances. This AVP can also be extended to add new AVPs allowing overload occurrances. This AVP can also be extended to add new AVPs
a reporting nodes to communicate additional information about allowing a reporting nodes to communicate additional information
handling an overload condition. about handling an overload condition.
If necessary, new extensions can also define new top-level AVPs. It If necessary, new extensions can also define new top-level AVPs. It
is, however, recommended that DOIC extensions use the OC-Supported- is, however, recommended that DOIC extensions use the OC-Supported-
Features and OC-OLR to carry all DOIC related AVPs. Features and OC-OLR to carry all DOIC related AVPs.
3.5. Simplified Example Architecture 3.5. Simplified Example Architecture
Figure 1 illustrates the simplified architecture for Diameter Figure 1 illustrates the simplified architecture for Diameter
overload information conveyance. overload information conveyance.
skipping to change at page 13, line 18 skipping to change at page 13, line 7
The reporting node MUST NOT include the OC-Supported-Features AVP, The reporting node MUST NOT include the OC-Supported-Features AVP,
OC-OLR AVP or any other overload control AVPs defined in extension OC-OLR AVP or any other overload control AVPs defined in extension
drafts in response messages for transactions where the request drafts in response messages for transactions where the request
message does not include the OC-Supported-Features AVP. Lack of the message does not include the OC-Supported-Features AVP. Lack of the
OC-Supported-Features AVP in the request message indicates that there OC-Supported-Features AVP in the request message indicates that there
is no reacting node for the transaction. is no reacting node for the transaction.
Based on the content of the OC-Supported-Features AVP in the request Based on the content of the OC-Supported-Features AVP in the request
message, the reporting node knows what overload control functionality message, the reporting node knows what overload control functionality
is supported by the reacting node. The reporting node then acts supported by reacting node(s). The reporting node then acts
accordingly for the subsequent answer messages it initiates. accordingly for the subsequent answer messages it initiates.
The reporting node MUST indicate support for one and only one The reporting node MUST indicate support for one and only one
abatement algorithm in the OC-Feature-Vector AVP. The abatement abatement algorithm in the OC-Feature-Vector AVP. The abatement
algorithm included MUST be from the set of abatement algorithms algorithm included MUST be from the set of abatement algorithms
contained in the request message's OC-Supported-Features AVP. The contained in the request messages OC-Supported-Features AVP. The
abatement algorithm included MUST indicate the abatement algorithm abatement algorithm included MUST indicate the abatement algorithm
the reporting node wants the reacting node to use when the reporting the reporting node wants the reacting node to use when the reporting
node enters an overload condition. node enters an overload condition.
The reporting node MUST NOT change the selected algorithm during a The reporting node MUST NOT change the selected algorithm during a
period of time that it is in an overload condition and, as a result, period of time that it is in an overload condition and, as a result,
is sending OC-OLR AVPs in answer messages. is sending OC-OLR AVPs in answer messages.
The reporting node SHOULD indicate support for other DOIC features The reporting node SHOULD indicate support for other DOIC features it
defined in extension drafts that it supports and that apply to the supports and that apply to the transaction.
transaction.
Note that not all DOIC features will apply to all Diameter Note that not all DOIC features will apply to all Diameter
applications or deployment scenarios. The features included in applications or deployment scenarios. The features included in
the OC-Feature-Vector AVP are based on local reporting node the OC-Feature-Vector AVP are based on local reporting node
policy. policy.
4.1.3. Agent Behavior 4.1.3. Agent Behavior
Diameter agents that support DOIC MUST ensure that all messages have Diameter agents that support DOIC MUST ensure that all messages have
the OC-Supporting-Features AVP. If a message handled by the DOIC the OC-Supporting-Features AVP. If a message handled by the DOIC
skipping to change at page 14, line 46 skipping to change at page 14, line 35
A realm-type OCS entry MAY be identified by the pair of Application- A realm-type OCS entry MAY be identified by the pair of Application-
Id and Realm-Id. Id and Realm-Id.
The host-type and realm-type OCS entries MAY include the following The host-type and realm-type OCS entries MAY include the following
information (the actual information stored is an implementation information (the actual information stored is an implementation
decision): decision):
o Sequence number (as received in OC-OLR) o Sequence number (as received in OC-OLR)
o Time of expiry (derived from OC-Validity-Duration AVP received in o Time of expiry (derived from validity duration as received in the
the OC-OLR AVP and time of reception of the message carrying OC- OC-OLR AVP and time of reception of the message carrying OC-OLR
OLR AVP) AVP)
o Selected Abatement Algorithm (as received in OC-Supported-Features o Selected Abatement Algorithm (as received in OC-Supported-Features
AVP) AVP)
o Abatement Algorithm specific input data (as received within the o Abatement Algorithm specific input data (as received within the
OC-OLR AVP, for example, OC-Reduction-Percentage for the Loss OC-OLR AVP, for example, Reduction Percentage for the Loss
abatement algorithm) abatement algorithm)
4.2.1.2. Overload Control State for Reporting Nodes 4.2.1.2. Overload Control State for Reporting Nodes
A reporting node SHOULD maintain OCS entries per supported Diameter A reporting node SHOULD maintain OCS entries per supported Diameter
application and per supported (and eventually selected) Abatement application and per supported (and eventually selected) Abatement
Algorithm. Algorithm.
An OCS entry MAY be identified by the pair of Application-Id and An OCS entry MAY be identified by the pair of Application-Id and
Abatement Algorithm. Abatement Algorithm.
skipping to change at page 18, line 16 skipping to change at page 17, line 51
last overload report for the overload condition was sent plus the last overload report for the overload condition was sent plus the
validity duration included in that overload report. validity duration included in that overload report.
4.2.2. Reacting Node Behavior 4.2.2. Reacting Node Behavior
When a reacting node sends a request it MUST determine if that When a reacting node sends a request it MUST determine if that
request matches an active OCS. request matches an active OCS.
If the request matches and active OCS then the reacting number MUST If the request matches and active OCS then the reacting number MUST
apply abatement treatment on the request. The abatement treatment apply abatement treatment on the request. The abatement treatment
applied depends on the abatement algorithm stored in the OCS. applied depends on the the abatement algorithm stored in the OCS.
For the Loss abatement algorithm defined in this specification, see For the Loss abatement algorithm defined in this specification, see
Section 5 for the abatement logic applied. Section 5 for the abatement logic applied.
If the abatement treatment results in throttling of the request and If the abatement treatment results in throttling of the request and
if the reacting node is an agent then the agent MUST send an if the reacting node is an agent then the agent MUST send an
appropriate error as defined in section Section 7. appropriate error as defined in section Section 7.
In the case that the OCS entry validity duration expires or has a In the case that the OCS entry validity duration expires or has a
validity duration of zero ("0"), meaning that it the reporting node validity duration of zero ("0"), meaning that it the reporting node
skipping to change at page 20, line 26 skipping to change at page 20, line 14
4.3. Protocol Extensibility 4.3. Protocol Extensibility
The overload control solution can be extended, e.g. with new traffic The overload control solution can be extended, e.g. with new traffic
abatement algorithms, new report types or other new functionality. abatement algorithms, new report types or other new functionality.
When defining a new extension a new feature bit MUST be defined for When defining a new extension a new feature bit MUST be defined for
the OC-Feature-Vector. This feature bit is used to communicate the OC-Feature-Vector. This feature bit is used to communicate
support for the new feature. support for the new feature.
The extension MAY define new AVPs for use in DOIC Capability The extention MAY define new AVPs for use in DOIC Capability
Announcement and for use in DOIC Overload reporting. These new AVP Anouncement and for use in DOIC Overload reporting. These new AVP
SHOULD be defined to be extensions to the OC-Supported-Features and SHOULD be defined to be extensions to the OC-Supported-Features and
OC-OLR AVPs defined in this document. OC-OLR AVPs defined in this document.
It should be noted that [RFC6733] defined Grouped AVP extension It should be noted that [RFC6733] defined Grouped AVP extension
mechanisms apply. This allows, for example, defining a new feature mechanisms apply. This allows, for example, defining a new feature
that is mandatory to be understood even when piggybacked on an that is mandatory to be understood even when piggybacked on an
existing applications. existing applications.
The handling of feature bits in the OC-Feature-Vector AVP that are The handling of feature bits in the OC-Feature-Vector AVP that are
not associated with overload abatement algorithms MUST be specified not associated with overload abatement algorithms MUST be specified
by the extensions that define the features. by the extensions that define the features.
When defining new report type values, the corresponding specification When defining new report type values, the corresponding specification
MUST define the semantics of the new report types and how they affect MUST define the semantics of the new report types and how they affect
the OC-OLR AVP handling. The specification MUST also reserve a the OC-OLR AVP handling. The specification MUST also reserve a
corresponding new feature bit in the OC-Feature-Vector AVP. corresponding new feature in the OC-Feature-Vector AVP.
The OC-OLR AVP can be expanded with optional sub-AVPs only if a The OC-OLR AVP can be expanded with optional sub-AVPs only if a
legacy DOIC implementation can safely ignore them without breaking legacy DOIC implementation can safely ignore them without breaking
backward compatibility for the given OC-Report-Type AVP value. If backward compatibility for the given OC-Report-Type AVP value. If
the new sub-AVPs imply new semantics for handling the indicated the new sub-AVPs imply new semantics for handling the indicated
report type, then a new OC-Report-Type AVP value MUST be defined. report type, then a new OC-Report-Type AVP value MUST be defined.
New features (feature bits in the OC-Feature-Vector AVP) and report New features (feature bits in the OC-Feature-Vector AVP) and report
types (in the OC-Report-Type AVP) MUST be registered with IANA. As types (in the OC-Report-Type AVP) MUST be registered with IANA. As
with any Diameter specification, new AVPs MUST also be registered with any Diameter specification, new AVPs MUST also be registered
skipping to change at page 21, line 37 skipping to change at page 21, line 27
request a percentage reduction in the amount of traffic sent. The request a percentage reduction in the amount of traffic sent. The
traffic impacted by the requested reduction depends on the type of traffic impacted by the requested reduction depends on the type of
overload report. overload report.
Reporting nodes use a strategy of applying abatement logic to the Reporting nodes use a strategy of applying abatement logic to the
requested percentage of request messages sent (or handled in the case requested percentage of request messages sent (or handled in the case
of agents) by the reacting node that are impacted by the overload of agents) by the reacting node that are impacted by the overload
report. report.
From a conceptual level, the logic at the reacting node could be From a conceptual level, the logic at the reacting node could be
outlined as follows. outlined as follows. In this discussion assume that the reacting
node is also the sending node.
1. An overload report is received and the associated overload state 1. An overload report is received and the associated overload state
is either saved or updated (if required) by the reacting node. is saved by the reacting node.
2. A new Diameter request is generated by the application running on 2. A new Diameter request is generated by the application running on
the reacting node. the reacting node.
3. The reacting node determines that an active overload report 3. The reacting node determines that an active overload report
applies to the request, as indicated by the corresponding OCS applies to the request.
entry.
4. The reacting node determines if abatement should be applied to 4. The reacting node determines if abatement should be applied to
the request. One approach that could be taken for each request the request. One approach that could be taken for each request
is to select a random number between 1 and 100. If the random is to select a random number between 1 and 100. If the random
number is less than the indicated reduction percentage then the number is less than the indicated reduction percentage then the
request is given abatement treatment, otherwise the request is request is given abatement treatment, otherwise the request is
given normal routing treatment. given normal routing treatment.
5.2. Reporting Node Behavior 5.2. Reporting Node Behavior
skipping to change at page 23, line 12 skipping to change at page 23, line 6
If reacting node comes out of the 100 percent traffic reduction as a If reacting node comes out of the 100 percent traffic reduction as a
result of the overload report timing out, the following concerns are result of the overload report timing out, the following concerns are
RECOMMENDED to be applied. The reacting node sending the traffic RECOMMENDED to be applied. The reacting node sending the traffic
should be conservative and, for example, first send "probe" messages should be conservative and, for example, first send "probe" messages
to learn the overload condition of the overloaded node before to learn the overload condition of the overloaded node before
converging to any traffic amount/rate decided by the sender. Similar converging to any traffic amount/rate decided by the sender. Similar
concerns apply in all cases when the overload report times out unless concerns apply in all cases when the overload report times out unless
the previous overload report stated 0 percent reduction. the previous overload report stated 0 percent reduction.
If the reacting node does not receive an OLR in messages sent to the If the reacting node does not receive an OLR in messages sent to the
formerly overloaded node then the reacting node SHOULD slowly formally overloaded node then the reacting node SHOULD slowly
increase the rate of traffic sent to the overloaded node. increase the rate of traffic sent to the overloaded node.
It is suggested that the reacting node decrease the amount of traffic It is suggested that the reacting node decrease the amount of traffic
given abatement treatment by 20% each second until the reduction is given abatement treatment by 20% each second until the reduction is
completely removed and no traffic is given abatement treatment. completely removed and no traffic is given abatement treatment.
The goal of this behavior is to reduce the probability of overload The goal of this behavior is to reduce the probability of overload
condition thrashing where an immediate transition from 100% condition thrashing where an immediate transition from 100%
reduction to 0% reduction results in the reporting node moving reduction to 0% reduction results in the reporting node moving
quickly back into an overload condition. quickly back into an overload condition.
skipping to change at page 24, line 32 skipping to change at page 24, line 24
The following capabilities are defined in this document: The following capabilities are defined in this document:
OLR_DEFAULT_ALGO (0x0000000000000001) OLR_DEFAULT_ALGO (0x0000000000000001)
When this flag is set by the DOIC node it means that the default When this flag is set by the DOIC node it means that the default
traffic abatement (loss) algorithm is supported. traffic abatement (loss) algorithm is supported.
6.3. OC-OLR AVP 6.3. OC-OLR AVP
The OC-OLR AVP (AVP code TBD2) is type of Grouped and contains the The OC-OLR AVP (AVP code TBD2) is type of Grouped and contains the
information necessary to convey an overload report on an overload information necessary to convey an overload report. The OC-OLR AVP
condition at the reporting node. The OC-OLR AVP does not explicitly does not explicitly contain all information needed by the reacting
contain all information needed by the reacting node to decide whether node to decide whether a subsequent request must undergo a throttling
a subsequent request must undergo a throttling process with the process with the received reduction percentage. The value of the OC-
received reduction percentage. The value of the OC-Report-Type AVP Report-Type AVP within the OC-OLR AVP indicates which implicit
within the OC-OLR AVP indicates which implicit information is information is relevant for this decision (see Section 6.6). The
relevant for this decision (see Section 6.6). The application the application the OC-OLR AVP applies to is the same as the Application-
OC-OLR AVP applies to is the same as the Application-Id found in the Id found in the Diameter message header. The host or realm the OC-
Diameter message header. The host or realm the OC-OLR AVP concerns OLR AVP concerns is determined from the Origin-Host AVP and/or
is determined from the Origin-Host AVP and/or Origin-Realm AVP found Origin-Realm AVP found in the encapsulating Diameter command. The
in the encapsulating Diameter command. The OC-OLR AVP is intended to OC-OLR AVP is intended to be sent only by a reporting node.
be sent only by a reporting node.
OC-OLR ::= < AVP Header: TBD2 > OC-OLR ::= < AVP Header: TBD2 >
< OC-Sequence-Number > < OC-Sequence-Number >
< OC-Report-Type > < OC-Report-Type >
[ OC-Reduction-Percentage ] [ OC-Reduction-Percentage ]
[ OC-Validity-Duration ] [ OC-Validity-Duration ]
* [ AVP ] * [ AVP ]
Note that if a Diameter command were to contain multiple OC-OLR AVPs Note that if a Diameter command were to contain multiple OC-OLR AVPs
they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs they all MUST have different OC-Report-Type AVP value. OC-OLR AVPs
with unknown values SHOULD be silently discarded by reacting nodes with unknown values SHOULD be silently discarded and the event SHOULD
and the event SHOULD be logged. be logged.
6.4. OC-Sequence-Number AVP 6.4. OC-Sequence-Number AVP
The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64. The OC-Sequence-Number AVP (AVP code TBD3) is type of Unsigned64.
Its usage in the context of overload control is described in Its usage in the context of overload control is described in
Section 4.2. Section 4.2.
From the functionality point of view, the OC-Sequence-Number AVP MUST From the functionality point of view, the OC-Sequence-Number AVP MUST
be used as a non-volatile increasing counter for a sequence of be used as a non-volatile increasing counter for a sequence of
overload reports between two DOIC nodes for the same overload overload reports between two DOIC nodes for the same overload
skipping to change at page 26, line 49 skipping to change at page 26, line 45
The value of the Destination-Realm AVP in the request matches the The value of the Destination-Realm AVP in the request matches the
value of the Origin-Realm AVP of the received message that value of the Origin-Realm AVP of the received message that
contained the OC-OLR AVP. contained the OC-OLR AVP.
The value of the Application-ID in the Diameter Header of the The value of the Application-ID in the Diameter Header of the
request matches the value of the Application-ID of the Diameter request matches the value of the Application-ID of the Diameter
Header of the received message that contained the OC-OLR AVP. Header of the received message that contained the OC-OLR AVP.
The OC-Report-Type AVP is envisioned to be useful for situations The OC-Report-Type AVP is envisioned to be useful for situations
where a reacting node needs to apply different overload treatments where a reacting node needs to apply different overload treatments
for different overload contexts. For example, the reacting node(s) for different "types" of overload. For example, the reacting node(s)
might need to throttle differently requests sent to a specific server might need to throttle differently requests sent to a specific server
(identified by the Destination-Host AVP in the request) and requests (identified by the Destination-Host AVP in the request) and requests
that can be handled by any server in a realm. that can be handled by any server in a realm.
6.7. OC-Reduction-Percentage AVP 6.7. OC-Reduction-Percentage AVP
The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32 The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
and describes the percentage of the traffic that the sender is and describes the percentage of the traffic that the sender is
requested to reduce, compared to what it otherwise would send. The requested to reduce, compared to what it otherwise would send. The
OC-Reduction-Percentage AVP applies to the default (loss) algorithm OC-Reduction-Percentage AVP applies to the default (loss) algorithm
skipping to change at page 30, line 39 skipping to change at page 30, line 39
A similar attack involves an otherwise authorized Diameter node that A similar attack involves an otherwise authorized Diameter node that
sends an inappropriate overload report. For example, a server for sends an inappropriate overload report. For example, a server for
the realm "example.com" might send an overload report indicating that the realm "example.com" might send an overload report indicating that
a competitor's realm "example.net" is overloaded. If other nodes act a competitor's realm "example.net" is overloaded. If other nodes act
on the report, they may falsely believe that "example.net" is on the report, they may falsely believe that "example.net" is
overloaded, effectively reducing that realm's capacity. Therefore, overloaded, effectively reducing that realm's capacity. Therefore,
it's critical that nodes validate that an overload report received it's critical that nodes validate that an overload report received
from a peer actually falls within that peer's responsibility before from a peer actually falls within that peer's responsibility before
acting on the report or forwarding the report to other peers. For acting on the report or forwarding the report to other peers. For
example, an overload report from a peer that applies to a realm not example, an overload report from an peer that applies to a realm not
handled by that peer is suspect. handled by that peer is suspect.
An attacker might use the information in an overload report to assist An attacker might use the information in an overload report to assist
in certain attacks. For example, an attacker could use information in certain attacks. For example, an attacker could use information
about current overload conditions to time a DoS attack for maximum about current overload conditions to time a DoS attack for maximum
effect, or use subsequent overload reports as a feedback mechanism to effect, or use subsequent overload reports as a feedback mechanism to
learn the results of a previous or ongoing attack. learn the results of a previous or ongoing attack.
9.2. Denial of Service Attacks 9.2. Denial of Service Attacks
skipping to change at page 34, line 50 skipping to change at page 34, line 50
Non supporting agents Non supporting agents
Due to the way that realm-routed requests are handled in Diameter Due to the way that realm-routed requests are handled in Diameter
networks, with the server selection for the request done by an networks, with the server selection for the request done by an
agent, it is recommended that deployments upgrade all agents with agent, it is recommended that deployments upgrade all agents with
direct connections to servers prior to enabling the DOIC solution direct connections to servers prior to enabling the DOIC solution
in the Diameter network. in the Diameter network.
Topology hiding interactions Topology hiding interactions
There exist proxies that implement what is referred to as Topology There exist proxies that implement what is refered to as Topology
Hiding. This can include cases where the agent modifies the Hiding. This can include cases where the agent modifies the
Origin-Host in answer messages. The behavior of the DOIC solution Origin-Host in answer messages. The behavior of the DOIC solution
is not well understood when this happens. As such, the DOIC is not well understood when this happens. As such, the DOIC
solution does not address this scenario. solution does not address this scenario.
Appendix C. Considerations for Applications Integrating the DOIC Appendix C. Considerations for Applications Integrating the DOIC
Solution Solution
This section outlines considerations to be taken into account when THis section outlines considerations to be taken into account when
integrating the DOIC solution into Diameter applications. integrating the DOIC solution into Diameter applications.
C.1. Application Classification C.1. Application Classification
The following is a classification of Diameter applications and The following is a classification of Diameter applications and
request types. This discussion is meant to document factors that requests. This discussion is meant to document factors that play
play into decisions made by the Diameter identity responsible for into decisions made by the Diameter identity responsible for handling
handling overload reports. overload reports.
Section 8.1 of [RFC6733] defines two state machines that imply two Section 8.1 of [RFC6733] defines two state machines that imply two
types of applications, session-less and session-based applications. types of applications, session-less and session-based applications.
The primary difference between these types of applications is the The primary difference between these types of applications is the
lifetime of Session-Ids. lifetime of Session-Ids.
For session-based applications, the Session-Id is used to tie For session-based applications, the Session-Id is used to tie
multiple requests into a single session. multiple requests into a single session.
The Credit-Control application defined in [RFC4006] is an example of
a Diameter session-based application.
In session-less applications, the lifetime of the Session-Id is a In session-less applications, the lifetime of the Session-Id is a
single Diameter transaction, i.e. the session is implicitly single Diameter transaction, i.e. the session is implicitly
terminated after a single Diameter transaction and a new Session-Id terminated after a single Diameter transaction and a new Session-Id
is generated for each Diameter request. is generated for each Diameter request.
For the purposes of this discussion, session-less applications are For the purposes of this discussion, session-less applications are
further divided into two types of applications: further divided into two types of applications:
Stateless applications: Stateless applications:
Requests within a stateless application have no relationship to Requests within a stateless application have no relationship to
each other. The 3GPP defined S13 application is an example of a each other. The 3GPP defined S13 application is an example of a
stateless application [S13], where only a Diameter command is stateless application [S13], --> where only a Diameter command is
defined between a client and a server and no state is maintained defined between a client and a server and no state is maintained
between two consecutive transactions. between two consecutive transactions.
Pseudo-session applications: Pseudo-session applications:
Applications that do not rely on the Session-Id AVP for Applications that do not rely on the Session-Id AVP for
correlation of application messages related to the same session correlation of application messages related to the same session
but use other session-related information in the Diameter requests but use other session-related information in the Diameter requests
for this purpose. The 3GPP defined Cx application [Cx] is an for this purpose. The 3GPP defined Cx application [Cx] is an
example of a pseudo-session application. example of a pseudo-session application.
The Credit-Control application defined in [RFC4006] is an example of
a Diameter session-based application.
The handling of overload reports must take the type of application The handling of overload reports must take the type of application
into consideration, as discussed in Appendix C.2. into consideration, as discussed in Appendix C.2.
C.2. Application Type Overload Implications C.2. Application Type Overload Implications
This section discusses considerations for mitigating overload This section discusses considerations for mitigating overload
reported by a Diameter entity. This discussion focuses on the type reported by a Diameter entity. This discussion focuses on the type
of application. Appendix C.3 discusses considerations for handling of application. Appendix C.3 discusses considerations for handling
various request types when the target server is known to be in an various request types when the target server is known to be in an
overloaded state. overloaded state.
skipping to change at page 39, line 13 skipping to change at page 39, line 13
Pseudo-session requests: Pseudo-session requests:
Throttling decisions for pseudo-session requests can take into Throttling decisions for pseudo-session requests can take into
consideration where individual requests fit into the overall consideration where individual requests fit into the overall
sequence of requests within the pseudo session. Requests that are sequence of requests within the pseudo session. Requests that are
earlier in the sequence might be throttled more aggressively than earlier in the sequence might be throttled more aggressively than
requests that occur later in the sequence. requests that occur later in the sequence.
Intra-session requests: Intra-session requests:
There are two types of intra-sessions requests, requests that There are two classes of intra-sessions requests. The first class
terminate a session and the remainder of intra-session requests. consists of requests that terminate a session. The second class
Implementors and operators may choose to throttle session- comprises requests that are used by the Diameter client and server
terminating requests less aggressively in order to gracefully to maintain the ongoing session state. Implementors and operators
terminate sessions, allow clean-up of the related resources (e.g. may choose to throttle session-terminating requests less
session state) and avoid the need for additional intra-session aggressively in order to gracefully terminate sessions, allow
requests. Favoring session-termination requests may reduce the clean-up of the related resources (e.g. session state) and avoid
session management impact on the overloaded entity. The default the need for additional intra-session requests. Favoring session-
handling of other intra-session requests might be to treat them termination requests may reduce the session management impact on
equally when making throttling decisions. There might also be the overloaded entity. The default handling of other intra-
application level considerations whether some request types are session requests might be to treat them equally when making
favored over others. throttling decisions. There might also be application level
considerations whether some request types are favored over others.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
Broadcom Broadcom
Porkkalankatu 24 Porkkalankatu 24
Helsinki FIN-00180 Helsinki FIN-00180
Finland Finland
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
 End of changes. 48 change blocks. 
109 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------080705080607070801010908-- From nobody Thu Oct 23 09:49:46 2014 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 2AAD81ACDA4 for ; Thu, 23 Oct 2014 09:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 dfX7d6HF7djU for ; Thu, 23 Oct 2014 09:49:38 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF941ACD81 for ; Thu, 23 Oct 2014 09:49:37 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-0c-5449319f47ae Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C6.58.04081.F9139445; Thu, 23 Oct 2014 18:49:35 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.145]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 18:49:35 +0200 From: Maria Cruz Bartolome To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Resolution to issue 69 and part of issue 23 Thread-Index: AQHP7bvnJeH5+Lu+jkWVySE0RoW1TZw95p8A Date: Thu, 23 Oct 2014 16:49:34 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209851D53@ESESSMB101.ericsson.se> References: <54473C8A.5030801@usdonovans.com> In-Reply-To: <54473C8A.5030801@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje58Q88Qg+5bxhZze1ewWWxo4nFg 8liy5CeTx6q3fawBTFFcNimpOZllqUX6dglcGbu7bzAXPOSpWLrxL2MD4xzOLkZODgkBE4nv m3vYIGwxiQv31gPZXBxCAkcZJTaePsII4SxhlLjV28QMUsUmYCdx6fQLJhBbRMBX4njnaRYQ W1jAXuLvkz52iLiDxMSzS4DiHEC2kcSlLW4gYRYBVYmWCY/AxvACtW648BNsjJCArsS7d79Z QWxOAT2J/qM/GEFsRqCDvp9aA1bDLCAucevJfCaIQwUkluw5zwxhi0q8fPyPFcJWklix/RIj RL2exI2pU9ggbG2JZQtfQ+0VlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxihanFiflphsZ 6aUWZSYXF+fn6eWllmxiBEbJwS2/DXYwvnzueIhRgINRiYc3YaZHiBBrYllxZe4hRmkOFiVx 3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYCzad2+a6f/pc3/Wferw/XTtqM+89ffk NS0Sm0s28N1LrwvwkJz4fNOXagPPZfd25/OE6O9UvLwxk6/YbPuUohTp5D3c136VPW39zP7l 6c8TZpG7Vv+5sWr1h83Va9WyeR8k6YSwXjg8pztWsbnJgTFw2ynJ+Z93/Pm7X3zdDk3bHh7f xQLXFW4qsRRnJBpqMRcVJwIAMVaM+XMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Fa4eVARPjmaRXcc-QeiViLS1XjA Subject: Re: [Dime] Resolution to issue 69 and part of issue 23 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, 23 Oct 2014 16:49:43 -0000 Hello Steve, In this paragraph, "reacting" shall be replaced by "reporting", two places: The reacting node MAY extend the validatity duration for an exis= ting overload report by sending a OLR with either the same or a new validity duration value. When doing so, the reacting node MUST = increase the sequence number in the new OLR sent. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: mi=E9rcoles, 22 de octubre de 2014 7:12 To: dime@ietf.org Subject: [Dime] Resolution to issue 69 and part of issue 23 I added Lionel's proposed wording to the reporting node sub section of the = overload report handling section. I also modified the first paragraph below and added the other two paragraph= s. Those changes were not directly related to issue 69 but were needed in = this section. The reporting node MAY update the overload report with new reduc= tion percentages. The reacting node MAY extend the validatity duration for an exis= ting overload report by sending a OLR with either the same or a new validity duration value. When doing so, the reacting node MUST = increase the sequence number in the new OLR sent. When sending an overload report with new values in any of the su= b AVPs for an existing overload condition, the reporting node MUST incr= ease the sequence number in the new OLR sent. I have attached the diff file. Regards, Steve From nobody Sun Oct 26 14:40:47 2014 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 324801A1A9E for ; Sun, 26 Oct 2014 14:40:46 -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 h1E6a-1hcCXV for ; Sun, 26 Oct 2014 14:40:44 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 460C61A1A8B for ; Sun, 26 Oct 2014 14:40:44 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p9so4698526lbv.7 for ; Sun, 26 Oct 2014 14:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+VxSTqOeopcQl10LsK6UIdTJOAD9n8nNHcqLLBwM5rk=; b=jhXgGhFrc403B2+dA7ux/Zx9Nghafg73Ob3pTBu8pKuZ41GMy74eUzndNoRz/JTIMg 0/TIAPAXU2sm4RZoEUcy+46QaU2Bsxz15p3ARmDwGBfHi2hYm3HX6V1ONbYvJHL4NCVD fhvU3vcoSQ62UVimPAzDWATrLQH0NvYsTKDDcaGjrQTd7gqle8JD9XUVC2b4cYjskiHX hhqRoa21ixRbVbMEWXOy/6nrA33hoz9hEOd1H3Z9A/ZsMOffx5JtBCkKxBsl1d9BvE8R maMxPiBngjpaD/cNCRQbVbhCGye3/vtCSU5Oa1NPeKu0/lkRSMUAX3u3KGmYROHLlROD 2/kg== X-Received: by 10.112.221.226 with SMTP id qh2mr19306551lbc.5.1414359642478; Sun, 26 Oct 2014 14:40:42 -0700 (PDT) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id x6sm4278456lbj.40.2014.10.26.14.40.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Oct 2014 14:40:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815218E40@DEMUMBX014.nsn-intra.net> Date: Sun, 26 Oct 2014 23:40:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <087A34937E64E74E848732CFF8354B9209852157@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D900066815218E40@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5i6P8vHW8OZZjqQDbJcsz71TeKQ Cc: "dime@ietf.org list" Subject: Re: [Dime] -04 review 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: Sun, 26 Oct 2014 21:40:46 -0000 Ulrich, Figure 1 illustrates the simplified architecture for Diameter overload information conveyance. =20 =20 Realm X Same or other Realms <--------------------------------------> <----------------------> =20 =20 +--^-----+ : (optional) : |Diameter| : : |Server A|--+ .--. : +---^----+ : .--. +--------+ | _( `. : |Diameter| : _( `. +---^----+ +--( )--:-| Agent |-:--( )--|Diameter| +--------+ | ( ` . ) ) : +-----^--+ : ( ` . ) ) | Client | |Diameter|--+ `--(___.-' : : `--(___.-' +-----^--+ |Server B| : : +---^----+ : : =20 End-to-end Overload Indication 1) <-----------------------------------------------> Diameter Application Y =20 Overload Indication A Overload Indication A' 2) <----------------------> <----------------------> standard base protocol standard base protocol =20 =20 =20 Figure 1: Simplified architecture choices for overload indication delivery =20 In Figure 1, the Diameter overload indication can be conveyed (1) end-to-end between servers and clients or (2) between servers and Diameter agent inside the realm and then between the Diameter agent and the clients[UW1] . [UW1] I guess I do not fully understand case (2) by "standard base = protocol" you mean CER/CEA and DWR/DWA ?? Not necessarily. It can be, though. The "standard base protocol" should = be replaced with "Diameter Application Y". - Jouni On Oct 25, 2014, at 3:32 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > =20 > please find my comments attached. > =20 > Best regards > Ulrich > <04-review UW.docx> From nobody Mon Oct 27 10:47:35 2014 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 4A6771A87AE; Mon, 27 Oct 2014 10:47:18 -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 IPYa2gE6OvMu; Mon, 27 Oct 2014 10:47:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3954E1A871B; Mon, 27 Oct 2014 10:45:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027174559.26683.4464.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 10:45:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Nc-9yjS-knb6Iss1OApf3pYQlcA Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-ovli-04.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, 27 Oct 2014 17:47:18 -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 Overload Indication Conveyance Authors : Jouni Korhonen Steve Donovan Ben Campbell Lionel Morand Filename : draft-ietf-dime-ovli-04.txt Pages : 39 Date : 2014-10-27 Abstract: This specification documents a Diameter Overload Control (DOC) base solution and the dissemination of the overload report information. Requirements The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-ovli-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-04 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 28 08:17:48 2014 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 D82B61A8A9E for ; Tue, 28 Oct 2014 08:17:46 -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 A5UXqfCrKnlv for ; Tue, 28 Oct 2014 08:17:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7DD1A8A81 for ; Tue, 28 Oct 2014 08:17:44 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 969923741EC for ; Tue, 28 Oct 2014 16:17:42 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 7EBBFC807F for ; Tue, 28 Oct 2014 16:17:42 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 16:17:42 +0100 From: To: "dime@ietf.org" Thread-Topic: Test Thread-Index: Ac/ywkzuqV86pUoESvug2Lh62NUYuw== Date: Tue, 28 Oct 2014 15:17:40 +0000 Message-ID: <16522_1414509462_544FB396_16522_1361_1_6B7134B31289DC4FAF731D844122B36E84C94E@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E84C94EPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.23.30920 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/TM-PvaIZg76MDzwhSAt6VbAeGwk Subject: [Dime] Test 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, 28 Oct 2014 15:17:47 -0000 --_000_6B7134B31289DC4FAF731D844122B36E84C94EPEXCVZYM13corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable please ignore ___________________________________________________________________________= ______________________________________________ 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_6B7134B31289DC4FAF731D844122B36E84C94EPEXCVZYM13corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

please ignore

______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E84C94EPEXCVZYM13corpora_-- From nobody Tue Oct 28 14:43:48 2014 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 722CB1AD0A1 for ; Tue, 28 Oct 2014 14:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pgaftj-3oxqn for ; Tue, 28 Oct 2014 14:43:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9A0E61AD0B9 for ; Tue, 28 Oct 2014 14:43:16 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9SLhE3s073806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Oct 2014 16:43:15 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ben Campbell Date: Tue, 28 Oct 2014 16:43:14 -0500 X-Mao-Original-Outgoing-Id: 436225394.571374-7a5e73cc9704cec454ff6ce2d6a56edf Content-Transfer-Encoding: quoted-printable Message-Id: <1EE50EC3-AF07-41D3-AB56-BDC93CA24EFF@nostrum.com> References: <20141025224431.22600.89722.idtracker@ietfa.amsl.com> To: "dime@ietf.org list" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/mbX6V3lZ0O6cMZesW4oVrD_zLy8 Subject: [Dime] Load Considerations 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, 28 Oct 2014 21:43:40 -0000 Hi, Early in the DOIC work, we decided to defer the "load" (not "overload") = related requirements from RFC 7068 until later. Since it looks like the = core DOIC draft is starting to stabilize, we should start thinking about = load conveyance soon. I put together a draft discussing several high = level architectural considerations that the working group will need to = consider in any "load conveyance" solution. This is _not_ a solution proposal. But I hope it will spur discussion = that can lead to a proposal down the line. Thanks! Ben. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > To: Ben Campbell , "Ben Campbell" > Subject: New Version Notification for = draft-campbell-dime-load-considerations-00.txt > Date: October 25, 2014 at 5:44:31 PM CDT >=20 >=20 > A new version of I-D, draft-campbell-dime-load-considerations-00.txt > has been successfully submitted by Ben Campbell and posted to the > IETF repository. >=20 > Name: draft-campbell-dime-load-considerations > Revision: 00 > Title: Architectural Considerations for Diameter Load = Information > Document date: 2014-10-25 > Group: Individual Submission > Pages: 9 > URL: = http://www.ietf.org/internet-drafts/draft-campbell-dime-load-consideration= s-00.txt > Status: = https://datatracker.ietf.org/doc/draft-campbell-dime-load-considerations/ > Htmlized: = http://tools.ietf.org/html/draft-campbell-dime-load-considerations-00 >=20 >=20 > Abstract: > 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. This document explores some architectural > considerations for a mechanism to send load information. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 From nobody Wed Oct 29 08:52:25 2014 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 4E2831A1A74 for ; Wed, 29 Oct 2014 08:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 nxtczzUqmLvv for ; Wed, 29 Oct 2014 08:52:23 -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 CF6001A1A5E for ; Wed, 29 Oct 2014 08:52:23 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62568 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XjVXo-000Amv-MQ for dime@ietf.org; Wed, 29 Oct 2014 08:52:22 -0700 Message-ID: <54510D34.3030104@usdonovans.com> Date: Wed, 29 Oct 2014 10:52:20 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/0RUBg1qiMb6zIhpGHbNJxMbv-Qs Subject: [Dime] test 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, 29 Oct 2014 15:52:24 -0000 Please ignore From nobody Wed Oct 29 09:12:13 2014 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 3C3A01A1B31; Wed, 29 Oct 2014 09:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=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 7vfVlEveNDMm; Wed, 29 Oct 2014 09:11:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F7C1A1B17; Wed, 29 Oct 2014 09:11:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141029161152.18379.88915.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 09:11:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5e3RroPlMD_brwZZRdtv6_QuVhQ Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-congestion-flow-attributes-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, 29 Oct 2014 16:12:01 -0000 --NextPart 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 Congestion and Filter Attributes Author(s) : B. Hirschman, et al Filename : draft-ietf-dime-congestion-flow-attributes Pages : 9 Date : 2014-10-29 This document defines optional ECN and filter related attributes that can be used for improved traffic identification, support of ECN and minimized filter administration within Diameter. RFC 5777 defines a Filter-Rule AVP that accommodates extensions for classification, conditions and actions. It 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. A Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g. packets) is not captured in Accounting applications, leaving administrators without useful information regarding the effectiveness or understanding of the filter definition. These optional attributes are forward and backwards compatible with RFC 5777. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-dime-congestion-flow-attributes-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-congestion-flow-attributes"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-10-29091152.I-D@ietf.org> --NextPart-- From nobody Wed Oct 29 09:52:45 2014 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 7C1D21A1B4F for ; Wed, 29 Oct 2014 09:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 T0CAl56EnZ8y for ; Wed, 29 Oct 2014 09:52:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:752]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC8E1A1BA3 for ; Wed, 29 Oct 2014 09:52:40 -0700 (PDT) Received: from BL2FFO11FD035.protection.gbl (10.173.160.31) by BL2FFO11HUB055.protection.gbl (10.173.161.155) with Microsoft SMTP Server (TLS) id 15.0.1049.20; Wed, 29 Oct 2014 16:52:17 +0000 Received: from plsasdm2.corp.sprint.com (144.230.168.26) by BL2FFO11FD035.mail.protection.outlook.com (10.173.161.131) with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Wed, 29 Oct 2014 16:52:17 +0000 Received: from pdaasen2.corp.sprint.com (pdaasen2.corp.sprint.com [144.226.111.130]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9TGqGdK005912 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Oct 2014 11:52:16 -0500 Received: from PLSWE13M08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by pdaasen2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9TGqGok005752 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Oct 2014 11:52:16 -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.847.32; Wed, 29 Oct 2014 11:52:15 -0500 Received: from PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c]) by PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c%15]) with mapi id 15.00.0847.030; Wed, 29 Oct 2014 11:52:15 -0500 From: "Bertz, Lyle T [CTO]" To: "dime@ietf.org" Thread-Topic: New version notification for draft-ietf-dime-congestion-flow-attributes-01.txt Thread-Index: Ac/zmFfoT6V7aDNLQpG0Oyvniz/ZkQ== Date: Wed, 29 Oct 2014 16:52:14 +0000 Message-ID: <938b341021364360b4992e07f1b1c74a@PLSWE13M07.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.27] Content-Type: multipart/alternative; boundary="_000_938b341021364360b4992e07f1b1c74aPLSWE13M07adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.168.26; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(164054003)(199003)(189002)(106466001)(108616004)(16236675004)(6806004)(31966008)(44976005)(2501002)(19617315012)(4396001)(19300405004)(68736004)(85306004)(33646002)(84326002)(2656002)(77096002)(84676001)(19580395003)(230783001)(71186001)(512954002)(15975445006)(15202345003)(86362001)(120916001)(229853001)(21056001)(92566001)(107046002)(99396003)(85852003)(2351001)(107886001)(30436002)(64706001)(20776003)(87936001)(97736003)(95666004)(76482002)(19625215002)(46102003)(110136001)(50986999)(54356999)(26826002)(80022003)(4546003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB055; H:plsasdm2.corp.sprint.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB055; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 03793408BA Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.168.26 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.168.26; helo=plsasdm2.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.230.168.26) smtp.mailfrom=Lyle.T.Bertz@sprint.com; X-OriginatorOrg: sprint.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dLIHb2BKh7YVkX85oygQeJuMqWI Subject: [Dime] New version notification for draft-ietf-dime-congestion-flow-attributes-01.txt 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, 29 Oct 2014 16:52:42 -0000 --_000_938b341021364360b4992e07f1b1c74aPLSWE13M07adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, An update to has been made to the draft (https://www.ietf.org/internet-draf= ts/draft-ietf-dime-congestion-flow-attributes-01.txt). Only examples were = added to the document. Comments are welcome. Thanks, Lyle ________________________________ 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_938b341021364360b4992e07f1b1c74aPLSWE13M07adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

An update to has been made to the draft (https://www.ietf.org/internet-drafts/draft-ietf-dime-congestio= n-flow-attributes-01.txt).  Only examples were added to the document.

 

Comments are welcome.


Thanks,

 

Lyle



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_938b341021364360b4992e07f1b1c74aPLSWE13M07adsprintcom_-- From nobody Wed Oct 29 12:16:37 2014 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 B8DA31A892E for ; Wed, 29 Oct 2014 12:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 sibCQ5RdMUPR for ; Wed, 29 Oct 2014 12:16:32 -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 DB6571A8928 for ; Wed, 29 Oct 2014 12:16:32 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63890 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XjYjP-0001Kl-3H for dime@ietf.org; Wed, 29 Oct 2014 12:16:31 -0700 Message-ID: <54513D0E.3050201@usdonovans.com> Date: Wed, 29 Oct 2014 14:16:30 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AcLrjJsyiBEv48GPHIjZrYm9yw4 Subject: [Dime] DOIC work remaining 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, 29 Oct 2014 19:16:34 -0000 All, Thanks to everyone who has helped with the generation of the -04 version of the DOIC specification . Hopefully we're getting close. As a reminder, the goal is to have a version of the draft ready for working group last call shortly after the Honolulu IETF meeting. I see the following items remaining: - As many end-to-end scrubs of the -04 draft as people have time to do. - Focused review of the security section. - Closing issue #58 - We have the following options. The default option is the first. 1 - Do nothing, leaving the wording that says the DOIC solution assumes a single source for realm reports 2 - Come to consensus on wording for either the synchronized sequence number or OC-SourceID alternatives - Close the remaining Editor's Notes in the document. - Section 4.1.3 Agent Behavior subsection of Capability Announcement section, dealing with wording around agent changing OC-Supported-Features header in request messages. - Section 4.2.3 Reporting Node Behavior of Overload Report Handling section, this is for issue 58. - Section 6.5 Oc-Validity-Duration AVP - Question of whether there should be an explicit maximum value. We can create a new version of the draft prior to the start of the IETF meeting if needed. See y'all in Hawaii. Aloha, Steve From nobody Wed Oct 29 12:29:39 2014 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 09C2B1A898A for ; Wed, 29 Oct 2014 12:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 pGlR4K3MvQ8d for ; Wed, 29 Oct 2014 12:29:33 -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 F0FE91A8989 for ; Wed, 29 Oct 2014 12:29:32 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63958 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XjYvy-0000oT-Q1 for dime@ietf.org; Wed, 29 Oct 2014 12:29:31 -0700 Message-ID: <5451401A.3050308@usdonovans.com> Date: Wed, 29 Oct 2014 14:29:30 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <54513D0E.3050201@usdonovans.com> In-Reply-To: <54513D0E.3050201@usdonovans.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iZgUeHllKSJDgwLAvNmHv6Kp-Wo Subject: Re: [Dime] DOIC work remaining 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, 29 Oct 2014 19:29:34 -0000 One other work item that I missed -- Ben sent his first take on conformance to requirements in RFC7068. There is an empty Appendix waiting for the results of this analysis. Steve On 10/29/14, 2:16 PM, Steve Donovan wrote: > All, > > Thanks to everyone who has helped with the generation of the -04 > version of the DOIC specification . Hopefully we're getting close. > > As a reminder, the goal is to have a version of the draft ready for > working group last call shortly after the Honolulu IETF meeting. > > I see the following items remaining: > > - As many end-to-end scrubs of the -04 draft as people have time to do. > > - Focused review of the security section. > > - Closing issue #58 - We have the following options. The default > option is the first. > > 1 - Do nothing, leaving the wording that says the DOIC solution > assumes a single source for realm reports > 2 - Come to consensus on wording for either the synchronized > sequence number or OC-SourceID alternatives > > - Close the remaining Editor's Notes in the document. > > - Section 4.1.3 Agent Behavior subsection of Capability Announcement > section, dealing with wording around agent changing > OC-Supported-Features header in request messages. > > - Section 4.2.3 Reporting Node Behavior of Overload Report Handling > section, this is for issue 58. > > - Section 6.5 Oc-Validity-Duration AVP - Question of whether there > should be an explicit maximum value. > > We can create a new version of the draft prior to the start of the > IETF meeting if needed. > > See y'all in Hawaii. > > Aloha, > > Steve > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Oct 29 13:54:12 2014 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 F3C521A8ADC for ; Wed, 29 Oct 2014 13:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 atwBbKb7euwK for ; Wed, 29 Oct 2014 13:54:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 A05321A8AD3 for ; Wed, 29 Oct 2014 13:54:09 -0700 (PDT) Received: from localhost ([::1]:59230 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XjaFq-0007h0-MO; Wed, 29 Oct 2014 13:54:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Wed, 29 Oct 2014 20:54:06 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/86 Message-ID: <057.0707e4d881bcc9f664ab48273afb2213@trac.tools.ietf.org> X-Trac-Ticket-ID: 86 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/wVuoruIl1pWm6ekXgFOiBbCmLA0 Cc: dime@ietf.org Subject: [Dime] [dime] #86 (draft-docdt-dime-ovli): Need Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 20:54:11 -0000 #86: Need Requirements Analysis Benoit asked us to include an analysis of how we meet the RFC7068 requirements. Ben has proposed text on the list. We need to discuss that text, and incorporate the results. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: task | Status: new Priority: major | Milestone: milestone1 Component: draft- | Version: docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Wed Oct 29 13:55:58 2014 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 8AACE1A8AE3 for ; Wed, 29 Oct 2014 13:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Rjkaxa1AinSm for ; Wed, 29 Oct 2014 13:55:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 3A1F21A8AEA for ; Wed, 29 Oct 2014 13:55:55 -0700 (PDT) Received: from localhost ([::1]:59352 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XjaHa-00088L-9P; Wed, 29 Oct 2014 13:55:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com X-Trac-Project: dime Date: Wed, 29 Oct 2014 20:55:54 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/87 Message-ID: <057.41b6354583a1406cbadde728b3f7ce55@trac.tools.ietf.org> X-Trac-Ticket-ID: 87 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ZLNCiPxE02ixnaTF13WMU_nL2NY Cc: dime@ietf.org Subject: [Dime] [dime] #87 (draft-docdt-dime-ovli): Security Considerations Out of Date X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 20:55:56 -0000 #87: Security Considerations Out of Date The security considerations have not been updated to reflect changes elsewhere. Some issues may no longer reply. We need to revise the text in that section. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft- | Version: docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Fri Oct 31 05:42:21 2014 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 B5F191A8730 for ; Fri, 31 Oct 2014 05:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 hOyWoOiRv1Dy for ; Fri, 31 Oct 2014 05:42:17 -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 245AC1A0056 for ; Fri, 31 Oct 2014 05:42:15 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61754 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XkBWv-000CDS-6J for dime@ietf.org; Fri, 31 Oct 2014 05:42:14 -0700 Message-ID: <545383A4.7070707@usdonovans.com> Date: Fri, 31 Oct 2014 07:42:12 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <087A34937E64E74E848732CFF8354B9209852157@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D900066815218E40@DEMUMBX014.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/RiN7DduNTKdQOXIGA-7xFbybSsw Subject: Re: [Dime] -04 review 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, 31 Oct 2014 12:42:19 -0000 This change will show up in the next revision of -05. Regards, Steve On 10/26/14, 4:40 PM, Jouni wrote: > Ulrich, > > Figure 1 illustrates the simplified architecture for Diameter > overload information conveyance. > > > Realm X Same or other Realms > <--------------------------------------> <----------------------> > > > +--^-----+ : (optional) : > |Diameter| : : > |Server A|--+ .--. : +---^----+ : .--. > +--------+ | _( `. : |Diameter| : _( `. +---^----+ > +--( )--:-| Agent |-:--( )--|Diameter| > +--------+ | ( ` . ) ) : +-----^--+ : ( ` . ) ) | Client | > |Diameter|--+ `--(___.-' : : `--(___.-' +-----^--+ > |Server B| : : > +---^----+ : : > > End-to-end Overload Indication > 1) <-----------------------------------------------> > Diameter Application Y > > Overload Indication A Overload Indication A' > 2) <----------------------> <----------------------> > standard base protocol standard base protocol > > > > Figure 1: Simplified architecture choices for overload indication > delivery > > In Figure 1, the Diameter overload indication can be conveyed (1) > end-to-end between servers and clients or (2) between servers and > Diameter agent inside the realm and then between the Diameter agent > and the clients[UW1] . > > [UW1] I guess I do not fully understand case (2) by "standard base protocol" you mean CER/CEA and DWR/DWA ?? > > Not necessarily. It can be, though. The "standard base protocol" should be replaced with "Diameter Application Y". > > - Jouni > > > > > > > On Oct 25, 2014, at 3:32 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > >> Steve, >> >> please find my comments attached. >> >> Best regards >> Ulrich >> <04-review UW.docx> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Fri Oct 31 09:22:35 2014 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 6B5791ACD32 for ; Fri, 31 Oct 2014 09:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 YVTK3EPcvSbc for ; Fri, 31 Oct 2014 09:22:32 -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 DD4D51ACD41 for ; Fri, 31 Oct 2014 09:22:32 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61839 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XkEy3-00049I-Mf for dime@ietf.org; Fri, 31 Oct 2014 09:22:29 -0700 Message-ID: <5453B740.40500@usdonovans.com> Date: Fri, 31 Oct 2014 11:22:24 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/alternative; boundary="------------060207040404010609070203" 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 - 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/nnjI2VZMEl1MD4WrGxVnniOt7Us Subject: [Dime] Review of draft-ietf-dime-group-signaling-04.txt 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, 31 Oct 2014 16:22:34 -0000 This is a multi-part message in MIME format. --------------060207040404010609070203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The following are my comments and questions resulting from a review of draft-ietf-dime-group-signaling-04.txt General comments: - The draft uses the term Diameter peer frequently in a way that does not seem to be correct. A Diameter peer is defined to be a Diameter node with a direct connection. The group signaling mechanism doesn't depend on communicating with a true Diameter peer. It would be better to have a different term. - The document might flow better if capability discovery was discussed before the session grouping logic, as session grouping depends on capability discovery. Just a personal preference. - Are there use cases identified that require supporting a session being in an unlimited number of session groups? This is probably an application specification issue, but putting a session in multiple groups appears to be pretty complicated to manage if all of the sessions in a group need to be in the same "application session state". - It seems dangerous to not allow a server to reject new group assignments. What happens if the server is out of resources for managing groups? Table in section 3.0 - First operation - Why is the peer the owner of the group, I thought the creator is the owner of the group. - Seventh operation - Why is this needed? Isn't this the same as operation six. - Eighth operation - Similar question. - Last operation - If I can delete all sessions in a group owned by my peer, why can't I just delete the session group as a whole? Section 4.1.1 - Isn't server creation of Session Groups dependent on the client supporting session groups? - Paragraph 5 - Shouldn't it also be possible for the server to create groups even if the client creates none (assuming the client supports groups)? - Second to last paragraph is not needed. A server that is RFC6733 compliant will always do as this says. - The last paragraph indicates how clients fall back to doing single session commands. There doesn't seem to be a mechanism for a server to do the same. Section 4.4 - The processing implies that the requested operation is applied to all sessions in all specified groups before an answer is sent. How likely is this to cause transactions to time-out and be retried? Section 5 - Second paragraph - Why MUST the proxy maintain consistency of session groups between clients and servers? What if the session groups are only meaningful between the client and the proxy? That's all for now. Regards, Steve --------------060207040404010609070203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The following are my comments and questions resulting from a review of draft-ietf-dime-group-signaling-04.txt

General comments:

- The draft uses the term Diameter peer frequently in a way that does not seem to be correct.  A Diameter peer is defined to be a Diameter node with a direct connection.  The group signaling mechanism doesn't depend on communicating with a true Diameter peer.  It would be better to have a different term.

- The document might flow better if capability discovery was discussed before the session grouping logic, as session grouping depends on capability discovery.  Just a personal preference.

- Are there use cases identified that require supporting a session being in an unlimited number of session groups?  This is probably an application specification issue, but putting a session in multiple groups appears to be pretty complicated to manage if all of the sessions in a group need to be in the same "application session state".

- It seems dangerous to not allow a server to reject new group assignments.  What happens if the server is out of resources for managing groups?

Table in section 3.0

- First operation - Why is the peer the owner of the group, I thought the creator is the owner of the group.
- Seventh operation - Why is this needed?  Isn't this the same as operation six.
- Eighth operation - Similar question.
- Last operation - If I can delete all sessions in a group owned by my peer, why can't I just delete the session group as a whole?

Section 4.1.1

- Isn't server creation of Session Groups dependent on the client supporting session groups?

- Paragraph 5 - Shouldn't it also be possible for the server to create groups even if the client creates none (assuming the client supports groups)?

- Second to last paragraph is not needed.  A server that is RFC6733 compliant will always do as this says. 

- The last paragraph indicates how clients fall back to doing single session commands.  There doesn't seem to be a mechanism for a server to do the same.

Section 4.4

- The processing implies that the requested operation is applied to all sessions in all specified groups before an answer is sent.  How likely is this to cause transactions to time-out and be retried?

Section 5

- Second paragraph - Why MUST the proxy maintain consistency of session groups between clients and servers?  What if the session groups are only meaningful between the client and the proxy?

That's all for now.

Regards,

Steve
--------------060207040404010609070203--