From nobody Wed Jan 16 10:09:24 2019 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54086124BE5; Wed, 16 Jan 2019 10:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com 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 siaQ4J1v9y71; Wed, 16 Jan 2019 10:09:20 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 34192124BAA; Wed, 16 Jan 2019 10:09:20 -0800 (PST) Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0GI9HCp078067 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Jan 2019 12:09:18 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547662158; bh=LudrXC/vTaH8tDC1LXXDEksgAtaAVR6RqerlUjbtgHg=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=QB9ssKmvAS30W/kOdOC0hwpzM9b/Y+nkDIaJUpkU5YI06d2q5mPzkRlHscpKZAggd qCnfnD4WLzwfVikxeSyROhTaGwkwnsEnptyWDPtT2iVFRFKqK6tFf2m5e8N46XWIbz rCFLWeRYUBHBh3+ZyFepbi1xBO6+6nwlrYHwIH+0= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45] From: Ben Campbell Message-Id: <1E942B8D-0C26-4DDF-9D2C-329F82AF9059@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_08389655-C2E1-42A7-951E-81DCD8A83D64"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 16 Jan 2019 12:09:17 -0600 In-Reply-To: Cc: dime@ietf.org To: draft-ietf-dime-doic-rate-control.all@ietf.org References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Dime] AD Evaluation of draft-ietf-dime-doic-rate-control-10 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jan 2019 18:09:22 -0000 --Apple-Mail=_08389655-C2E1-42A7-951E-81DCD8A83D64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, IETF Last Call ends today, and unless I missed something there has been = no comments that require changes beyond those I made below. However, = IDNits also complains about the reference in the abstract. Normally the = RFC editor prefers to have no references in the abstract. Fixing this = would mean simply removing =E2=80=9C[RFC7683]=E2=80=9D from the = abstract. This will probably end up on the IESG Telechat on 24 January. If you are = able to make any updates this week it would be helpful. Otherwise please = wait until after the telechat. Thanks! Ben. > On Dec 21, 2018, at 5:06 PM, Ben Campbell wrote: >=20 > Hi, >=20 > This is my AD evaluation for draft-ietf-dime-doic-rate-control-10. I = previously reviewed version 8, however since some time has passed I = reviewed this version =E2=80=9Cfrom scratch=E2=80=9D. >=20 > In general the draft is in good shape. I think it=E2=80=99s ready for = IETF Last Call, which I will request shortly. Please note the last call = window will be extended due to the upcoming holidays. >=20 > I have a few minor comments that can be resolved along with any last = call feedback. >=20 > Thanks! >=20 > Ben. >=20 > ------------------------------------- >=20 > =C2=A74, paragraphs 2 and 3: Am I correct to assume that, as new DOIC = algorithms get added, nodes could support both of these and something = else? If so, then in paragraph 2 I suggest s/ =E2=80=9C support both the = loss and rate based abatement algorithms=E2=80=9D/ "support at least the = loss and rate based abatement algorithms=E2=80=9D >=20 > ... and in paragraph 3, I suggest adding something to the effect of = =E2=80=9C... and MAY indicate support for others.=E2=80=9D >=20 > (nit) =C2=A75.5, 2nd paragraph: "It is also possible for the reporting = node to send overload > reports with the rate algorithm indicated when the reporting node > is not in an overloaded state.=E2=80=9D >=20 > I suggest s/ =E2=80=9Cindicated when=E2=80=9D / =E2=80=9Cindicated = even when=E2=80=9D >=20 > (nit) =C2=A75.6, first paragraph: The algorithm is detailed in 7.3. >=20 > =C2=A77.3.1: "To apply abatement treatment to new Diameter requests at = the rate > specified in the OC-Maximum-Rate AVP value sent by the reporting node > to its reacting nodes, the reacting node MAY use the proposed default > algorithm for rate-based control or any other equivalent algorithm > that forward messages in conformance with the upper bound of 1/T > messages per second.=E2=80=9D >=20 > This is redundant to similar normative text in =C2=A75.6. I suggest = keeping just one (probably this one since it=E2=80=99s more precise) and = use descriptive language for the other. >=20 > =C2=A79: Do the authors think that the rate algorithm might be more = effective at DoS mitigation than the loss algorithm? If so, that might = be worth a mention in the security considerations. >=20 >=20 --Apple-Mail=_08389655-C2E1-42A7-951E-81DCD8A83D64 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlw/c00ACgkQgFZKbJXz 1A39Wg/+KpnegIeJGuTtZpYc1cPKhjjPyqB69dH/YQp0ezwouoLp6Xf1AJMV+c8J JPPGS06uFDxrUlIV/sIIXuGufMWDmM+oZ1FRQbMCJcLwbrccbLhfkrjfg6WdS2sC JVvgLQLvgIuh/P6MuZdb9NlebdT/JAvAGu21Xy6f5EGfOosR0AORugjW8ITH4M4g pIaXqULD+zi0OYfZUhh7Po2Gizzrp01DWtEQgq4rvdRFrm7/Tw0JksL4RO7vxwoT EHN0qkYPDmaeByoWXJSTBiKFwcbkiVl2c7jwSNNSsLzBc7IGYAKZiYmzpGGU+3l4 2iqZuugJ3hbCpTXGST1OGrA1oRqSl6HOSjC3inlHhkjUJa7F/JEvPWfUD5zY+1E/ TXY8xHL87tG1IWIqouUOSWXHQ48UgZ8TsffItIrjI0aq4+/GNZ4vqqLjtEf1nJ5A 894NcsK3IxHGeqMcJ75OKS5uiUR/KeEd/jsZHxjy7eBdHhwc/NP62rHtjjcscIxZ ute0YvmYHVMWjjdyrHBKmKLLgZyALuqtWOD/+9C9sByc5HkTOSjydAktsYLASj3O ut7io4pgaj3HaaSMkNlQH9MMglUzMO76P5lwoN3b4RpaqTQHwIunk4p8BzB293yM y8S8M5jRpMGMYB/l3B23P/jJLgF6cu2+MP5wGg8U5S0yyKSq1xk= =TggG -----END PGP SIGNATURE----- --Apple-Mail=_08389655-C2E1-42A7-951E-81DCD8A83D64-- From wojciech.szczypta@motorolasolutions.com Thu Jan 17 08:57:36 2019 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2F7130E8E for ; Thu, 17 Jan 2019 08:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.589 X-Spam-Level: X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=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 EjPigITlKh3M for ; Thu, 17 Jan 2019 08:57:34 -0800 (PST) Received: from mx0b-0019e102.pphosted.com (mx0a-0019e102.pphosted.com [67.231.149.242]) (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 9655E130E77 for ; Thu, 17 Jan 2019 08:57:34 -0800 (PST) Received: from pps.filterd (m0074413.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0HGqEON010001 for ; Thu, 17 Jan 2019 10:57:34 -0600 Received: from mail-vk1-f197.google.com (mail-vk1-f197.google.com [209.85.221.197]) by mx0a-0019e102.pphosted.com with ESMTP id 2q2wgm81u0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 17 Jan 2019 10:57:33 -0600 Received: by mail-vk1-f197.google.com with SMTP id y72so2337145vky.14 for ; Thu, 17 Jan 2019 08:57:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GZvvhfVTo3g0asNJHDdfBj9RctqSRb8osGtvcP4jcDg=; b=fPv3vLgxNJ1+LMDneLDg/+uxcuwsoj/ickN2s2OA+0eeFiAZwoDEwThWh0T+0mZBXI zOq6NYlYzC4j+2oYv1T9LE8jiQotwKHWz1281f7t8fA21dcOYT/d/sPlv7O2axzJHAZA TqKm8eeUFevZOc79AOWVKmK3cdi37oivV23SV/ywprMMU70Y6QVc+97cQjvjwt/0pBD7 kmuNI0Tn8YD9Dq3rAtefMbmyovrKikLn4wMJyxaIxDIVhtuoSiFYmQsFBE/lImpcooAz EIWG49BhRj6xym7u8Zz6eSz/l45GY3esbhFWkFPh1WmLvSM0SLU1XEZCIYegV2pHAN3y L2hQ== X-Gm-Message-State: AJcUukeYnQ707TGI/L8DpO3zjttIeQOltAGUhHe1WgNMloP3Fbc8kMjM JjPDHMOMpxgxnxTfXwFhhqwxkZW7lsE71mLBqeLzvxJzRT2ymSg/xe2a2j1aQqpJKIaTVaPhUYP ZqyrbrklEIAIkU+VWoSL3 X-Received: by 2002:ab0:526:: with SMTP id 35mr6119239uax.25.1547744252138; Thu, 17 Jan 2019 08:57:32 -0800 (PST) X-Google-Smtp-Source: ALg8bN6zQblBG91+gPqUP0DAmDZW7p6Qmy6K5ONyM4yUaQNKHIpefC/rSF604TP6c8Ljpw3cM+41YbBTBCIJ4OKyqnI= X-Received: by 2002:ab0:526:: with SMTP id 35mr6119224uax.25.1547744251750; Thu, 17 Jan 2019 08:57:31 -0800 (PST) MIME-Version: 1.0 From: Wojciech Szczypta Date: Thu, 17 Jan 2019 17:57:20 +0100 Message-ID: To: dime@ietf.org Content-Type: multipart/alternative; boundary="000000000000544aaf057faa4af7" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=39 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901170121 Archived-At: X-Mailman-Approved-At: Thu, 17 Jan 2019 09:54:25 -0800 Subject: [Dime] Mail regarding draft-ietf-dime-rfc3588bis - failover (handling not delivered/non-acknowledged STR) and session information X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jan 2019 16:59:08 -0000 --000000000000544aaf057faa4af7 Content-Type: text/plain; charset="UTF-8" Hello, I have a problem with fail-over procedure interpretation described in RFC 6733. We believe that Diameter stack implementation, that removes session information after sending STR before it received the acknowledgment, does not follow RFC 6733. Scenario: a peer established connection with a Diameter server (using SCTP) and the peer activated an user session on a Diameter server. After some time the peer has to terminate the session, so it's initiating the STR to Diameter server, but at the point of time, when peer sends the message a network failure occurs, that causes STR never reaches the server (and server never acknowledges the STR). Our application is build on top of the Diameter stack. When the application sends the message to the Diameter stack the connection is up. According to the Diameter stack, the link is still operational at the point of time, when the message is passed down to the SCTP stack. However the STR never reaches the destined Diameter server due to network failure. In fact we can't even see the STR on the network interface. We suspect a race-condition occurs, when SCTP stack receives the STR from Diameter stack, the SCTP already knows that there is problem with connection We see in the network capture that peer re-tries sending DWR and Diameter server re-tries to SACK previous DWR and retries to send DWA to peer the previous DWR. The main problem is that since Diameter stack "thinks" the message was sent successfully to the server it removes the session information without waiting for the answer. Since the session information is removed by the Diameter stack, there is no way the application can request STR re-transmission, after the connection is re-estbablished. Any further AAR or STR requests are ignored by the Diameter stack. The vendor providing the Diameter stack claims that their RFC 6733 implementation is correct and it's up to SCTP stack to take care of re-transmission. However the problem is not with the non-delivery of the STR but with lack of possibility to request STR re-transmission, making this communication unreliable. We believe the Diameter stack implementation does not follow the RFC, however our interpretation is that RFC 6733 isn't clear about what should happen in case the STR is not be delivered or acknowledged. The section 5.5.4. Failover and Failback Procedures in the RFC 6733 focuses on the using alternate path (if possible), but it does look more like a recommendation than hard requirement. There is a section in RFC 6733 which says: * Session state (associated with a Session-Id) MUST be freed upon* * receipt of the Session-Termination-Request, Session-Termination-* * Answer, expiration of authorized service time in the Session-Timeout* * AVP, and according to rules established in a particular Diameter* * application.* In our scenario session state was freed before receiving STA, so our interpretation is Diameter stack implementation doesn't follow this part of RFC - it shouldn't remove this information if it hasn't received the STA. Note: We are not using Session-Timeout AVP, so we need to make sure that STR was delivered and acknowledged by the Diameter server, otherwise the dedicated bearer will not be removed. Regards. *Wojciech SzczyptaMotorola Solutions Systems Polska* motorolasolutions.com --000000000000544aaf057faa4af7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I hav= e a problem with fail-over procedure interpretation described in RFC 6733.= =C2=A0
We believe that Diameter stack implementation, that remove= s session information after sending STR before it received the acknowledgme= nt, does not follow RFC 6733.

Scenario: a peer established connection with a Diameter server (using S= CTP) and the peer activated an user session on a Diameter server.=C2=A0
After some time the peer has to terminate the session, s= o it's initiating the STR to Diameter server, but at the point of time,= when peer sends the message a network failure occurs, that causes STR neve= r reaches the server (and server never acknowledges the STR).

Our application is build on top of the = Diameter stack.=C2=A0
When the application sends the = message to the Diameter stack the connection is up.=C2=A0
According to the Diameter stack, the link is still operational at the = point of time, when the message is passed down to the SCTP stack.=C2=A0
However the STR never reaches the destined Diameter serv= er due to network failure. In fact we can't even see the STR on the net= work interface.=C2=A0
We suspect a race-condition occ= urs, when SCTP stack receives the STR from Diameter stack, the SCTP already= knows that there is problem with connection
We see in the networ= k capture that peer re-tries sending DWR and Diameter server re-tries to SA= CK previous DWR and retries to send DWA to peer the previous DWR.

The main problem is that since Diameter stack "thinks" t= he message was sent successfully to the server it removes the session infor= mation without waiting for the answer.
Since the session info= rmation is removed by the Diameter stack, there is no way the application c= an request STR re-transmission, after the connection is re-estbablished.
Any further AAR or STR requests are ignored by the Diameter stack.<= /div>

The vendor providing the Diameter stack claims tha= t their RFC 6733 implementation is correct and it's up to SCTP stack to= take care of re-transmission.=C2=A0
However the problem is not w= ith the non-delivery of the STR but with lack of possibility to request STR= re-transmission, making this communication unreliable.=C2=A0
We = believe the Diameter stack implementation does not follow the RFC, however = our interpretation is that RFC 6733 isn't clear about what should happe= n in case the STR is not be delivered or acknowledged.

The section=C2=A05.5.4.=C2=A0 Failover and Failback Procedures in = the RFC 6733 focuses on the using alternate path (if possible), but it does= look more like a recommendation than hard requirement.

There is a section in RFC 6733 which=C2=A0 says:
= =C2=A0Session state (associated with a Session-Id) MUST be freed upon
=C2=A0 =C2=A0receipt of the Session-Termination-Request, Sessio= n-Termination-
=C2=A0 =C2=A0Answer, expiration of authoriz= ed service time in the Session-Timeout
=C2=A0 =C2=A0AVP, a= nd according to rules established in a particular Diameter
=C2=A0 =C2=A0application.

In our scenar= io session state was freed before receiving STA, so our interpretation is D= iameter stack implementation doesn't follow this part of RFC - it shoul= dn't remove this information if it hasn't received the STA.
Note: We are not using Session-Timeout AVP, so we need to make sure that= STR was delivered and acknowledged by the Diameter server, otherwise the d= edicated bearer will not be removed.

Regards.
Wojciech Szczypta
Motorola Solutions = Systems Polska
motorolasolutions.com
--000000000000544aaf057faa4af7-- From nobody Thu Jan 17 23:46:21 2019 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43D7131151 for ; Thu, 17 Jan 2019 23:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pQzs3vCneXqQ for ; Thu, 17 Jan 2019 23:46:16 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 5E436131150 for ; Thu, 17 Jan 2019 23:46:16 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id p6so9822896lfc.1 for ; Thu, 17 Jan 2019 23:46:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=63uJt22TkbKhXAr/H2xqGL2c3nPk9AxJZzzjTaviSTI=; b=EzTnxQOZaYYBohYfv8PIwxWC5FF/gJ6sL+SdcNwCFl0v0tZpW/ZjeGhLEggJ8ByS7K Ov9zqcB2N0gCZagt4gBmMcviy0DlI+op6+vVUP8q1iDKDnYf0zq0IW4cugnN0E1yDSao o1cEHl/6F+Q120hwtLowDfbS63Uot6l6nagtT1DUn44akb1qdSDUwjKt0zasxG4Vv2Pr ZVnG6fU9z2O5G4afUiMFTes5cLBwn7/6x9DzOd0+YuMZPV7TUHQsJ5ljAnRctkC0uFvE JmSfyWU9bvvzryh+CJ2YBa5lFvL9yKrZ+n29PfQMGwlPqFz5l0/P5HZAVUZkRMz96fC0 36HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=63uJt22TkbKhXAr/H2xqGL2c3nPk9AxJZzzjTaviSTI=; b=Mac0IddxK0Zqgg2qoYUnfTnV/btTKE6dZytCT48bbjJRg71wEozpo0zOVkxKU8phjl IdPmi5bhycjl6PrObMJMfezB3M6rJ34Gm5+1MD6uo/YiezdkihgawbRrD1p1k/cUufjc FauiRFe3Xb+5kMkl6NkJwyNIessRBJxuTdAuqasbLBB0F1hs1cyeAgpbJfr/7XkgG4I9 ozUObWnWw4wX8s8uCWL6jUaSD8RsDeAhB6Hx9hgH0expyKpOHvbvr0GRHZ0ewo4VrLj6 +/RxqIJAPd9ydMZT3r/FbzUWkalJd0TFY6kMf7cKmMI7Yyhnvt67r294gYT3eoMwHzLg 1fRA== X-Gm-Message-State: AJcUukeUv1NIHE+nLn+qE4UiIgtdDSwjbWmyOPXterpH4zBtW7Myf1vJ ii7if/gicLWgSH+py8kgCEgO3k118PBHMferjz8= X-Google-Smtp-Source: ALg8bN5cYQ02NbGaB7mNKMsXK9jHUQ7K+3jAwbCG/XbwsbEfU4/LVk/8cxDFyPUMmKo/yYcEm6XUfIimC0n1et6jWTY= X-Received: by 2002:ac2:51af:: with SMTP id f15mr2243127lfk.44.1547797574392; Thu, 17 Jan 2019 23:46:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Naveen Kottapalli Date: Fri, 18 Jan 2019 13:15:59 +0530 Message-ID: To: Wojciech Szczypta Cc: "dime@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009b2329057fb6b477" Archived-At: Subject: Re: [Dime] Mail regarding draft-ietf-dime-rfc3588bis - failover (handling not delivered/non-acknowledged STR) and session information X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 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, 18 Jan 2019 07:46:20 -0000 --0000000000009b2329057fb6b477 Content-Type: text/plain; charset="UTF-8" Comments inline. Yours, Naveen. On Thu, 17 Jan 2019 at 23:24, Wojciech Szczypta < wojciech.szczypta@motorolasolutions.com> wrote: > Hello, > > I have a problem with fail-over procedure interpretation described in RFC > 6733. > We believe that Diameter stack implementation, that removes session > information after sending STR before it received the acknowledgment, does > not follow RFC 6733. > > Scenario: a peer established connection with a Diameter server (using > SCTP) and the peer activated an user session on a Diameter server. > After some time the peer has to terminate the session, so it's initiating > the STR to Diameter server, but at the point of time, when peer sends the > message a network failure occurs, that causes STR never reaches the server > (and server never acknowledges the STR). > > Our application is build on top of the Diameter stack. > When the application sends the message to the Diameter stack the > connection is up. > According to the Diameter stack, the link is still operational at the > point of time, when the message is passed down to the SCTP stack. > However the STR never reaches the destined Diameter server due to network > failure. In fact we can't even see the STR on the network interface. > We suspect a race-condition occurs, when SCTP stack receives the STR from > Diameter stack, the SCTP already knows that there is problem with connection > We see in the network capture that peer re-tries sending DWR and Diameter > server re-tries to SACK previous DWR and retries to send DWA to peer the > previous DWR. > > The main problem is that since Diameter stack "thinks" the message was > sent successfully to the server it removes the session information without > waiting for the answer. > Naveen] Stack has to wait for STA to come back before deleting the session. > Since the session information is removed by the Diameter stack, there is > no way the application can request STR re-transmission, after the > connection is re-estbablished. > Any further AAR or STR requests are ignored by the Diameter stack. > > The vendor providing the Diameter stack claims that their RFC 6733 > implementation is correct and it's up to SCTP stack to take care of > re-transmission. > However the problem is not with the non-delivery of the STR but with lack > of possibility to request STR re-transmission, making this communication > unreliable. > We believe the Diameter stack implementation does not follow the RFC, > however our interpretation is that RFC 6733 isn't clear about what should > happen in case the STR is not be delivered or acknowledged. > > The section 5.5.4. Failover and Failback Procedures in the RFC 6733 > focuses on the using alternate path (if possible), but it does look more > like a recommendation than hard requirement. > > There is a section in RFC 6733 which says: > * Session state (associated with a Session-Id) MUST be freed upon* > * receipt of the Session-Termination-Request, Session-Termination-* > * Answer, expiration of authorized service time in the Session-Timeout* > * AVP, and according to rules established in a particular Diameter* > * application.* > Naveen] I see that the specification is clear here. It says that session state MUST be freed upon receipt of STR (by server) and not after sending STR (by client). > > In our scenario session state was freed before receiving STA, so our > interpretation is Diameter stack implementation doesn't follow this part of > RFC - it shouldn't remove this information if it hasn't received the STA. > Note: We are not using Session-Timeout AVP, so we need to make sure that > STR was delivered and acknowledged by the Diameter server, otherwise the > dedicated bearer will not be removed. > > Regards. > > *Wojciech SzczyptaMotorola Solutions Systems Polska* > motorolasolutions.com > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --0000000000009b2329057fb6b477 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comments inline.

Yours,
Naveen.


On Thu, 17 Jan 2019 at 23:24, Wojciech Szczypta <= ;wojciech.szczyp= ta@motorolasolutions.com> wrote:
=
Hello,

I have a problem with fail-over procedure interpretation= described in RFC 6733.=C2=A0
We believe that Diameter stack impl= ementation, that removes session information after sending STR before it re= ceived the acknowledgment, does not follow RFC 6733.
=
Scenario: a peer established connection with a D= iameter server (using SCTP) and the peer activated an user session on a Dia= meter server.=C2=A0
After some time the peer has to t= erminate the session, so it's initiating the STR to Diameter server, bu= t at the point of time, when peer sends the message a network failure occur= s, that causes STR never reaches the server (and server never acknowledges = the STR).

Our application = is build on top of the Diameter stack.=C2=A0
When the= application sends the message to the Diameter stack the connection is up.= =C2=A0
According to the Diameter stack, the link is s= till operational at the point of time, when the message is passed down to t= he SCTP stack.=C2=A0
However the STR never reaches th= e destined Diameter server due to network failure. In fact we can't eve= n see the STR on the network interface.=C2=A0
We susp= ect a race-condition occurs, when SCTP stack receives the STR from Diameter= stack, the SCTP already knows that there is problem with connection
<= div>We see in the network capture that peer re-tries sending DWR and Diamet= er server re-tries to SACK previous DWR and retries to send DWA to peer the= previous DWR.

The main problem is that since Diameter st= ack "thinks" the message was sent successfully to the server it r= emoves the session information without waiting for the answer.
Naveen] Stack has to wait for STA to= come back before deleting the session.=C2=A0
Since the session information is removed= by the Diameter stack, there is no way the application can request STR re-= transmission, after the connection is re-estbablished.
Any furthe= r AAR or STR requests are ignored by the Diameter stack.

The vendor providing the Diameter stack claims that their RFC 6733 i= mplementation is correct and it's up to SCTP stack to take care of re-t= ransmission.=C2=A0
However the problem is not with the non-delive= ry of the STR but with lack of possibility to request STR re-transmission, = making this communication unreliable.=C2=A0
We believe the Diamet= er stack implementation does not follow the RFC, however our interpretation= is that RFC 6733 isn't clear about what should happen in case the STR = is not be delivered or acknowledged.

The secti= on=C2=A05.5.4.=C2=A0 Failover and Failback Procedures in the RFC 6733 focus= es on the using alternate path (if possible), but it does look more like a = recommendation than hard requirement.

There is a s= ection in RFC 6733 which=C2=A0 says:
=C2=A0Session state = (associated with a Session-Id) MUST be freed upon
=C2=A0 = =C2=A0receipt of the Session-Termination-Request, Session-Termination-<= /div>
=C2=A0 =C2=A0Answer, expiration of authorized service time in = the Session-Timeout
=C2=A0 =C2=A0AVP, and according to rul= es established in a particular Diameter
=C2=A0 =C2=A0appli= cation.
Naveen] I = see that the specification is clear here.=C2=A0 It says that session state = MUST be freed upon receipt of STR (by server) and not after sending STR (by= client).=C2=A0

In our scenario session state was freed before receiving STA, so o= ur interpretation is Diameter stack implementation doesn't follow this = part of RFC - it shouldn't remove this information if it hasn't rec= eived the STA.
Note: We are not using Session-Timeout AVP, so we = need to make sure that STR was delivered and acknowledged by the Diameter s= erver, otherwise the dedicated bearer will not be removed.

Regards.
Wojciech Szczypta
Motorola Solutions Systems Polska
motorolasolutions.com
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--0000000000009b2329057fb6b477-- From nobody Mon Jan 21 07:04:22 2019 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18487130F2B; Mon, 21 Jan 2019 07:04:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-dime-doic-rate-control@ietf.org, Lionel Morand , dime-chairs@ietf.org, lionel.morand@orange.com, dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154808306002.8052.6002254450365375868.idtracker@ietfa.amsl.com> Date: Mon, 21 Jan 2019 07:04:20 -0800 Archived-At: Subject: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dime-doic-rate-control-10=3A_=28with_COMMENT=29?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 15:04:20 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dime-doic-rate-control-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The security considerations of rfc7683 have an own section on non-complaint nodes (section 10.3). While this is discussed in rfc7683, I think it is especially important for this document to remind the reader that there may be non-compliant nodes that may send with a higher than indicated rate. I would recommend to add one more statement to the security considerations section of this doc and potentially point the reader explicitly at section 10.3 of rfc7683. Two comments on normative language: 1) Section 5.6: "Any algorithm implemented MUST result in the correct rate of traffic being sent to the reporting node." I would recommend to maybe change this to: "Any algorithm implemented MUST correctly limit the maximum rate of traffic being sent to the reporting node." Otherwise I would think this is hard to implement in practice. 2) Section 7.2: "... the reporting node MUST periodically evaluate its overload state..." Not sure if the normative language is really appropriate here as this does not impact interoperability, nor can be checked. If at all, I guess I would recommend a "SHOULD" instead. And two more editorial comments: 1) As section 7.3 only describes (in quite some detail) an example algorithm, I would rather have put this in an appendix. But I guess that's a matter of taste... 2) I don't think section 8.2. is needed. From nobody Mon Jan 21 13:03:04 2019 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C9B1288BD; Mon, 21 Jan 2019 13:03:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Susan Hares To: Cc: dime@ietf.org, draft-ietf-dime-doic-rate-control.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154810458138.8188.8411786024206076306@ietfa.amsl.com> Date: Mon, 21 Jan 2019 13:03:01 -0800 Archived-At: Subject: [Dime] Opsdir last call review of draft-ietf-dime-doic-rate-control-10 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 21:03:02 -0000 Reviewer: Susan Hares Review result: Ready Steve and Eric: I have reveiwed this document as part of the operational directorate (ops-dir) ongoing effort to review all IETF documents being process by the IESG for operational aspects. These comments are to aid the authors and the NM/OPS Area Directors. The document editors and the WG chairs hsould treat these comments as any other last call comments. Status: ready, with 2 operator questions and 1 yang question. The question are just things to think about for the authors and ADS. Questions: The documentis readable and aligns with RFC7683 and draft-ietf-dime-agent-overload. The language in this document also aligns with language in the SIP Overload Control (SOC) document [RFC7415]. As I am not familar with current DIAMETER deployments, i've got a few operational questions for the authors to consider: 1) If a operator where deploying this new algorithm, what type of deployment considerations would be necessary? Should certain topologies of Diameter deployments utilize certain overload algorithms? 2) What failure modes will the operator see in the current overload abatement that would encourage the operator to spend the effort to go to this new DOIC rate limit? As a researcher and implementer, sections 1 and 7 were sufficient to answer these questions. However, I would ask the authors, WG chairs, and OPS/NM ADs to determine if these are sufficient for the normal operators. Question 3: Just for my own understanding, is there a plan to control DIAMETER protocols with YANG modules? From nobody Tue Jan 22 16:06:52 2019 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C414D1311A4; Tue, 22 Jan 2019 16:06:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-dime-doic-rate-control@ietf.org, Lionel Morand , dime-chairs@ietf.org, lionel.morand@orange.com, dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154820200372.13175.6427829494337126533.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2019 16:06:43 -0800 Archived-At: Subject: [Dime] Spencer Dawkins' Yes on draft-ietf-dime-doic-rate-control-10: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 00:06:44 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-dime-doic-rate-control-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for doing this work, and for basing it on SIP Overload Control. It's nice when protocol designers adopt good ideas from each other. There are three SHOULDs in Section 5.1, Reporting Node Overload Control State, I'd like to understand better. A reporting node that uses the rate abatement algorithm SHOULD maintain reporting node Overload Control State (OCS) for each reacting node to which it sends a rate Overload Report (OLR). ^^ This one - I'm guessing that this is "SHOULD unless you're still writing code upgrading an implementation that treats all reacting nodes the same way", based on this next sentence, but I'm guessing. Why wouldn't you do this? This is different from the behavior defined in [RFC7683] where a single loss percentage sent to all reacting nodes. A reporting node SHOULD maintain OCS entries when using the rate abatement algorithm per supported Diameter application, per targeted reacting node and per report type. ^^ Your answer to my previous question is likely to help me understand this one, but I'm guessing reasons why you wouldn't do this. A rate OCS entry is identified by the tuple of Application-Id, report type and DiameterIdentity of the target of the rate OLR. The rate OCS entry SHOULD include the rate allocated to the reacting note. ^^ I'm really interested on this one - does the rate abatement algorithm work without knowing the rate that's allocated? but assuming that it does work, I'm still guessing why you wouldn't do this. A reporting node that has selected the rate overload abatement algorithm MUST indicate the rate requested to be applied by DOIC reacting nodes in the OC-Maximum-Rate AVP included in the OC-OLR AVP. All other elements for the OCS defined in [RFC7683] and [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS when using the rate abatement algorithm. From nobody Tue Jan 22 16:11:35 2019 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D021F1311A4; Tue, 22 Jan 2019 16:11:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-dime-doic-rate-control@ietf.org, Lionel Morand , dime-chairs@ietf.org, lionel.morand@orange.com, dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154820228584.13271.9727761853618479099.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2019 16:11:25 -0800 Archived-At: Subject: [Dime] Adam Roach's No Objection on draft-ietf-dime-doic-rate-control-10: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 00:11:26 -0000 Adam Roach has entered the following ballot position for draft-ietf-dime-doic-rate-control-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who worked on this document. I have a handful of editorial comments on its contents that the editor may wish to consider when revising it to address the I-D nits identified by the document shepherd. --------------------------------------------------------------------------- §1: > of reporting nodes when subjected to rapidly changing loads. The Nit: "...rapidly-changing..." > One of the benefits of a rate based algorithm over the loss algorithm Nit: "...rate-based..." > to distribute it's load over the set of reacting nodes from which it Nit: "...its load..." > specify the amount of traffic on a per reacting node basis implies Nit: "...per-reacting-node basis..." > traffic to that reacting node. If the number of reacting node > changes, either because new nodes are added, nodes are removed from Nit: "...number of reacting nodes..." > Conveyance (DOIC) solution [RFC7683] to add support for the rate > based overload abatement algorithm. Nit: "...rate-based..." --------------------------------------------------------------------------- §4: > As defined in [RFC7683], a DOIC reporting node supporting the rate > feature MUST select a single abatement algorithm Consider whether normatively reiterating normative language from another specification makes sense. In the general case, this is a bad idea, since it opens the door to conflicting normative definitions of behavior. Non-normative restatement of behavior with a citation to the document that has the normative description is typically safer. --------------------------------------------------------------------------- §5.1: > This is different from the behavior defined in [RFC7683] where a > single loss percentage sent to all reacting nodes. Nit: "...percentage is sent..." (consider also: "...where a reporting node sends a single loss percentage to all reacting nodes.") --------------------------------------------------------------------------- §5.2: > OC-OLR AVP as an element of the abatement algorithm specific portion Nit: "...abatement-algorithm-specific portion..." --------------------------------------------------------------------------- §5.3: > A reporting node that has selected the rate overload abatement > algorithm and enters an overload condition MUST indicate rate as the > abatement algorithm in the resulting reporting node OCS entries. > > A reporting node that has selected the rate abatement algorithm and > enters an overload condition MUST indicate the selected rate in the > resulting reporting node OCS entries. These paragraphs are similar enough that it's kind of tricky to pull out the intended distinction being made. Consider: A reporting node that has selected the rate overload abatement algorithm and enters an overload condition MUST indicate rate as the abatement algorithm and MUST indicate the selected rate in the resulting reporting node OCS entries. --------------------------------------------------------------------------- §5.6: > Other algorithms for controlling the rate MAY be implemented by > the reacting node. Any algorithm implemented MUST result in the > correct rate of traffic being sent to the reporting node. It's not clear why this paragraph is indented. In some RFCs, it's conventional to indent non-normative editor's notes to help with clarity. The presence of normative language in this paragraph points away from that usage. Consider either un-indenting this paragraph, or explaining the way in which this document uses indented paragraphs (e.g., in the Introduction) --------------------------------------------------------------------------- §7. Rate Based Abatement Algorithm Nit: "Rate-Based..." --------------------------------------------------------------------------- §8.1: > New AVPs defined by this specification are listed in Section 6. All > AVP codes are allocated from the 'Authentication, Authorization, and > Accounting (AAA) Parameters' AVP Codes registry. This is a bit confusing -- it's not clear to me whether the information in §6.3 requires IANA action. It would probably be best to be a bit more explicit in this section about specifically which actions IANA needs to take. --------------------------------------------------------------------------- §8.3: > All DOIC report types defined in the future MUST indicate whether or > not the rate algorithm can be used with that report type. It is also unclear what actions IANA is expected to perform based on this input. --------------------------------------------------------------------------- §10: Either remove or (preferably) populate this section. From nobody Wed Jan 23 11:03:18 2019 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCC3130F86; Wed, 23 Jan 2019 11:03:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-dime-doic-rate-control@ietf.org, Lionel Morand , dime-chairs@ietf.org, lionel.morand@orange.com, dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154827019075.7547.9421622385944852216.idtracker@ietfa.amsl.com> Date: Wed, 23 Jan 2019 11:03:10 -0800 Archived-At: Subject: [Dime] Benjamin Kaduk's No Objection on draft-ietf-dime-doic-rate-control-10: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 19:03:16 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dime-doic-rate-control-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this well-written document! My comments are all essentially editorial in nature. One comment of a general note regards the usage of the word "indicate" -- usually when I read "indicate" I expect that to be part of some protocol message or other formal data structure, but IIUC the OCS is entirely a local matter, so "indicating" something in the OCS could be equally well said as "storing" or "noting" or similar. (I do see other similar usage of "indicate" in RFC 7683, so it's unclear that there are really any grounds for changing the usage in this document.) Section 4 nit: Saying that nodes MUST indicate support for *both* loss and rate seems to duplicate the requirement from RFC 7683 and would potentially complicate future updates. The descriptive note about "nodes supporting the rate feature will support both" seems a better way to phrase things. Section 5.1 Is keeping track of how much a reacting node is actually sending considered to not be part of the OCS (as opposed to the allocated rate, which is part of the OCS as noted here)? Section 6.2 This extension does not define new overload report types. The existing report types of host and realm defined in [RFC7683] apply to the rate control algorithm. The peer report type defined in [I-D.ietf-dime-agent-overload] also applies to the rate control algorithm. side note: I'm curious how the directionality is such that the report type applies to the algorithm, as opposed to the other way around. Section 7.1 Upon receiving the overload report with a target maximum Diameter request rate, each reacting node applies abatement treatment for new Diameter requests towards the reporting node. (nit?) My (hasty) reading of 7683 is that "abatement treatment" means either diversion or throttling, and that traffic processed normally is not considered to receive "abatement treatment". If that reading is correct, then this text is suggesting that no new requests receive normal treatment after the reception of an OLR with a target rate, which does not seem quite right. Section 7.2 Note that the value of OC-Maximum-Rate AVP (in request messages per second) for the rate algorithm provides an upper bound on the traffic sent by the reacting node to the reporting node. I see that this is not using normative language, and that the following paragraph does clarify the caveats, but "upper bound" usually is read as "strict upper bound", and there are several ways in which this bound could (at least temporarily) not be strict. Perhaps "loose upper bound" is better phrasing. Section 7.3.1 Perhaps note explicitly that "//" denotes comments? In determining whether or not to transmit a specific message, the reacting node can use any algorithm that limits the message rate to the OC-Maximum-Rate AVP value in units of messages per second. For ease of discussion, we define T = 1/[OC-Maximum-Rate] as the target inter-Diameter request interval. It may be strictly deterministic, or it may be probabilistic. It may, or may not, have a tolerance nit: The intervening sentence defining 'T' seems to change the binding of "It" away from "the algorithm". Note that when the OC-Maximum-Rate value is 0 with a non-zero OC- Validity-Duration, then the reacting node should apply abatement treatment to 100% of Diameter requests destined to the overloaded reporting node. However, when the OC-Validity-Duration value is 0, the reacting node should stop applying abatement treatment. nit: this paragraph seems like it would be better placed elsewhere, as its content is independent of any particular throttling algorithm. Reporting nodes with a very large number of reacting nodes, each with a relatively small arrival rate, will generally benefit from a smaller value for TAU in order to limit queuing (and hence response times) at the reporting node when subjected to a sudden surge of traffic from all reacting nodes. Conversely, a reporting node with a relatively small number of reacting nodes, each with proportionally larger arrival rate, will benefit from a larger value of TAU. Am I correct in assuming that "larger" and "smaller" values of TAU here are to be measured with respect to T (i.e., as a ratio)? This may be worth stating more explicitly. Section 8.3 Do you want to add this requirement as a "Note" on the IANA registry itself? Section 9 Other than what Mirja has already noted, I only have one minor remark. It seems that an attacker that can set up reacting nodes has a slightly different way to disrupt legitimate traffic when "rate" is used vs. "loss", but the details of any attack depend on implementation behavior at the reporting node (e.g., whether it divides its total capacity evenly amongst reacting nodes or uses a more complicated allocation scheme). And since an attacker that can set up new reacting nodes is almost certainly able to send traffic from those nodes, in practice there is no substantial difference, so the decision to ignore this difference and just refer to the 7683 security considerations seems justified. From nobody Thu Jan 24 15:07:50 2019 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A1E1311EA for ; Thu, 24 Jan 2019 15:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 EPcsGDV7rOdP for ; Thu, 24 Jan 2019 15:07:47 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (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 E64B91311DE for ; Thu, 24 Jan 2019 15:07:46 -0800 (PST) Received: from [97.99.21.33] (port=54553 helo=SDmac.lan) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gmo5p-00AMS5-Tq for dime@ietf.org; Thu, 24 Jan 2019 15:07:46 -0800 To: dime@ietf.org References: From: Steve Donovan Message-ID: Date: Thu, 24 Jan 2019 17:07:28 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------53CDD9873D6E2B6D6095021B" X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] AD Evaluation of draft-ietf-dime-doic-rate-control-10 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 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, 24 Jan 2019 23:07:49 -0000 This is a multi-part message in MIME format. --------------53CDD9873D6E2B6D6095021B Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Ben, I've updated the document based on our comments. See more below. Steve On 12/21/18 5:06 PM, Ben Campbell wrote: > Hi, > > This is my AD evaluation for draft-ietf-dime-doic-rate-control-10. I previously reviewed version 8, however since some time has passed I reviewed this version “from scratch”. > > In general the draft is in good shape. I think it’s ready for IETF Last Call, which I will request shortly. Please note the last call window will be extended due to the upcoming holidays. > > I have a few minor comments that can be resolved along with any last call feedback. > > Thanks! > > Ben. > > ------------------------------------- > > §4, paragraphs 2 and 3: Am I correct to assume that, as new DOIC algorithms get added, nodes could support both of these and something else? If so, then in paragraph 2 I suggest s/ “ support both the loss and rate based abatement algorithms”/ "support at least the loss and rate based abatement algorithms” SRD> No, only loss is required to be supported. The statement is that, because loss is always required, supporting rate implies supporting loss and rate. I don't think a change is required here. > > .... and in paragraph 3, I suggest adding something to the effect of “... and MAY indicate support for others.” SRD> I agree this is a good change. > > (nit) §5.5, 2nd paragraph: "It is also possible for the reporting node to send overload > reports with the rate algorithm indicated when the reporting node > is not in an overloaded state.” > > I suggest s/ “indicated when” / “indicated even when” SRD> Okay. > > (nit) §5.6, first paragraph: The algorithm is detailed in 7.3. > > §7.3.1: "To apply abatement treatment to new Diameter requests at the rate > specified in the OC-Maximum-Rate AVP value sent by the reporting node > to its reacting nodes, the reacting node MAY use the proposed default > algorithm for rate-based control or any other equivalent algorithm > that forward messages in conformance with the upper bound of 1/T > messages per second.” > > This is redundant to similar normative text in §5.6. I suggest keeping just one (probably this one since it’s more precise) and use descriptive language for the other. SRD> Okay, I changed 5.6 to the following: When determining if abatement treatment should be applied to a request being sent to a reporting node that has selected the rate overload abatement algorithm, the reacting node can choose to use the algorithm detailed in Section 7. > > §9: Do the authors think that the rate algorithm might be more effective at DoS mitigation than the loss algorithm? If so, that might be worth a mention in the security considerations. SRD> Good suggestion. I've added the following paragraph to the security section: In addition, the rate algorithm could be used to handle DoS attacks more effectively than the loss algorithm. > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------53CDD9873D6E2B6D6095021B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Ben,

I've updated the document based on our comments.  See more below.

Steve

On 12/21/18 5:06 PM, Ben Campbell wrote:
Hi,

This is my AD evaluation for draft-ietf-dime-doic-rate-control-10. I previously reviewed version 8, however since some time has passed I reviewed this version “from scratch”.

In general the draft is in good shape. I think it’s ready for IETF Last Call, which I will request shortly. Please note the last call window will be extended due to the upcoming holidays.

I have a few minor comments that can be resolved along with any last call feedback.

Thanks!

Ben.

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

§4, paragraphs 2 and 3: Am I correct to assume that, as new DOIC algorithms get added, nodes could support both of these and something else? If so, then in paragraph 2 I suggest s/ “ support both the loss and rate based abatement algorithms”/ "support at least the loss and rate based abatement algorithms”
SRD> No, only loss is required to be supported.  The statement is that, because loss is always required, supporting rate implies supporting loss and rate.  I don't think a change is required here.

.... and in paragraph 3, I suggest adding something to the effect of “... and MAY indicate support for others.”
SRD> I agree this is a good change.

(nit) §5.5, 2nd paragraph: "It is also possible for the reporting node to send overload
reports with the rate algorithm indicated when the reporting node
is not in an overloaded state.”

I suggest s/ “indicated when” / “indicated even when”
SRD> Okay.

(nit) §5.6, first paragraph: The algorithm is detailed in 7.3.


§7.3.1: "To apply abatement treatment to new Diameter requests at the rate
specified in the OC-Maximum-Rate AVP value sent by the reporting node
to its reacting nodes, the reacting node MAY use the proposed default
algorithm for rate-based control or any other equivalent algorithm
that forward messages in conformance with the upper bound of 1/T
messages per second.”

This is redundant to similar normative text in §5.6. I suggest keeping just one (probably this one since it’s more precise) and use descriptive language for the other.
SRD> Okay, I changed 5.6 to the following:

   When determining if abatement treatment should be applied to a
   request being sent to a reporting node that has selected the rate
   overload abatement algorithm, the reacting node can choose to
   use the algorithm detailed in Section 7. 

§9: Do the authors think that the rate algorithm might be more effective at DoS mitigation than the loss algorithm? If so, that might be worth a mention in the security considerations.
SRD> Good suggestion.  I've added the following paragraph to the security section:

   In addition, the rate algorithm could be used to handle DoS attacks more effectively than the loss algorithm.





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

--------------53CDD9873D6E2B6D6095021B-- From nobody Thu Jan 24 15:35:02 2019 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E10E130F49 for ; Thu, 24 Jan 2019 15:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 IVJAXATxiPel for ; Thu, 24 Jan 2019 15:34:59 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (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 22E34130F40 for ; Thu, 24 Jan 2019 15:34:59 -0800 (PST) Received: from [97.99.21.33] (port=54735 helo=SDmac.lan) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gmoWF-00AdGW-Ss for dime@ietf.org; Thu, 24 Jan 2019 15:34:58 -0800 To: dime@ietf.org References: <154808306002.8052.6002254450365375868.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: <932f60b6-6f7f-be0e-0c80-4c6d98777046@usdonovans.com> Date: Thu, 24 Jan 2019 17:34:46 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <154808306002.8052.6002254450365375868.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------77E61070AEDDEA8E2F5ECE2A" X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dime-doic-rate-control-10=3A_=28with_COMMENT=29?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 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, 24 Jan 2019 23:35:01 -0000 This is a multi-part message in MIME format. --------------77E61070AEDDEA8E2F5ECE2A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Mirja, Thanks for the comments. I've updated the document per my replies below. Regards, Steve On 1/21/19 9:04 AM, Mirja Kühlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-dime-doic-rate-control-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The security considerations of rfc7683 have an own section on non-complaint > nodes (section 10.3). While this is discussed in rfc7683, I think it is > especially important for this document to remind the reader that there may be > non-compliant nodes that may send with a higher than indicated rate. I would > recommend to add one more statement to the security considerations section of > this doc and potentially point the reader explicitly at section 10.3 of rfc7683. SRD> I can add a statement if people feel strongly about it. It does seem a bit redundant as the first paragraph of the security considerations section already has a reference back to the security considerations section of rfc 7683. > > Two comments on normative language: > > 1) Section 5.6: "Any algorithm implemented MUST result in the > correct rate of traffic being sent to the reporting node." > I would recommend to maybe change this to: > "Any algorithm implemented MUST correctly limit the maximum > rate of traffic being sent to the reporting node." > Otherwise I would think this is hard to implement in practice. SRD> I like your wording better and have updated the document accordingly. > > 2) Section 7.2: "... the reporting node MUST periodically evaluate its overload > state..." Not sure if the normative language is really appropriate here as this > does not impact interoperability, nor can be checked. If at all, I guess I > would recommend a "SHOULD" instead. SRD> I agree in principle but this was carried over from RFC7415 upon which the rate algorithm is based. I suggest changing it to SHOULD unless there are other objections. > > And two more editorial comments: > > 1) As section 7.3 only describes (in quite some detail) an example algorithm, I > would rather have put this in an appendix. But I guess that's a matter of > taste... SRD> If I remember correctly, this was an appendix at one point and got moved to a section. I'd prefer to leave it as is given it is a matter of taste. > > 2) I don't think section 8.2. is needed. SRD> I'll remove it unless I hear any objections to the suggestion. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------77E61070AEDDEA8E2F5ECE2A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mirja,

Thanks for the comments.  I've updated the document per my replies below.

Regards,

Steve

On 1/21/19 9:04 AM, Mirja Kühlewind wrote:
Mirja Kühlewind has entered the following ballot position for
draft-ietf-dime-doic-rate-control-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The security considerations of rfc7683 have an own section on non-complaint
nodes (section 10.3). While this is discussed in rfc7683, I think it is
especially important for this document to remind the reader that there may be
non-compliant nodes that may send with a higher than indicated rate. I would
recommend to add one more statement to the security considerations section of
this doc and potentially point the reader explicitly at section 10.3 of rfc7683.
SRD> I can add a statement if people feel strongly about it.  It does seem a bit redundant as the first paragraph of the security considerations section already has a reference back to the security considerations section of rfc 7683.

Two comments on normative language:

1) Section 5.6: "Any algorithm implemented MUST result in the
      correct rate of traffic being sent to the reporting node."
I would recommend to maybe change this to:
"Any algorithm implemented MUST correctly limit the maximum
 rate of traffic being sent to the reporting node."
Otherwise I would think this is hard to implement in practice.
SRD> I like your wording better and have updated the document accordingly.

2) Section 7.2: "... the reporting node MUST periodically evaluate its overload
state..." Not sure if the normative language is really appropriate here as this
does not impact interoperability, nor can be checked. If at all, I guess I
would recommend a "SHOULD" instead.
SRD> I agree in principle but this was carried over from RFC7415 upon which the rate algorithm is based.  I suggest changing it to SHOULD unless there are other objections. 

And two more editorial comments:

1) As section 7.3 only describes (in quite some detail) an example algorithm, I
would rather have put this in an appendix. But I guess that's a matter of
taste...
SRD> If I remember correctly, this was an appendix at one point and got moved to a section.  I'd prefer to leave it as is given it is a matter of taste.

2) I don't think section 8.2. is needed.
SRD> I'll remove it unless I hear any objections to the suggestion.


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

--------------77E61070AEDDEA8E2F5ECE2A-- From nobody Thu Jan 24 15:42:19 2019 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEE21311F9 for ; Thu, 24 Jan 2019 15:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 9-thXfw8xdrI for ; Thu, 24 Jan 2019 15:42:15 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (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 DDC32131215 for ; Thu, 24 Jan 2019 15:42:15 -0800 (PST) Received: from [97.99.21.33] (port=54784 helo=SDmac.lan) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gmodI-00Ahd2-Co for dime@ietf.org; Thu, 24 Jan 2019 15:42:15 -0800 To: dime@ietf.org References: <154810458138.8188.8411786024206076306@ietfa.amsl.com> From: Steve Donovan Message-ID: <71b3d38a-ac90-8ac7-0aa3-8a6c83d37534@usdonovans.com> Date: Thu, 24 Jan 2019 17:42:03 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <154810458138.8188.8411786024206076306@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------0EB645FECEC4AC41C06D9EEC" X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] Opsdir last call review of draft-ietf-dime-doic-rate-control-10 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 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, 24 Jan 2019 23:42:17 -0000 This is a multi-part message in MIME format. --------------0EB645FECEC4AC41C06D9EEC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Susan, Thank you for your review and comments. Please see my responses inline. Regards, Steve On 1/21/19 3:03 PM, Susan Hares wrote: > Reviewer: Susan Hares > Review result: Ready > > Steve and Eric: > > I have reveiwed this document as part of the operational directorate (ops-dir) > ongoing effort to review all IETF documents being process by the IESG for > operational aspects. These comments are to aid the authors and the NM/OPS Area > Directors. The document editors and the WG chairs hsould treat these comments > as any other last call comments. > > Status: ready, with 2 operator questions and 1 yang question. The question > are just things to think about for the authors and ADS. > > Questions: > > The documentis readable and aligns with RFC7683 and > draft-ietf-dime-agent-overload. The language in this document also aligns > with language in the SIP Overload Control (SOC) document [RFC7415]. > > As I am not familar with current DIAMETER deployments, i've got a few > operational questions for the authors to consider: > > 1) If a operator where deploying this new algorithm, > what type of deployment considerations would > be necessary? Should certain topologies > of Diameter deployments utilize certain > overload algorithms? > > 2) What failure modes will the operator see > in the current overload abatement that > would encourage the operator to > spend the effort to go to this new DOIC > rate limit? > > As a researcher and implementer, sections 1 and 7 were sufficient > to answer these questions. However, I would ask the authors, > WG chairs, and OPS/NM ADs to determine if these are sufficient > for the normal operators. SRD> We had multiple operators involved in the development of this draft, in fact, one of the authors works for an operator. As such, I'm confident that their concerns have been addressed. > > Question 3: Just for my own understanding, > is there a plan to control DIAMETER protocols with YANG > modules? SRD> Not to my knowledge. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------0EB645FECEC4AC41C06D9EEC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Susan,

Thank you for your review and comments.

Please see my responses inline.

Regards,

Steve

On 1/21/19 3:03 PM, Susan Hares wrote:
Reviewer: Susan Hares
Review result: Ready

Steve and Eric:

I have reveiwed this document as part of the  operational directorate (ops-dir)
ongoing effort to review all IETF documents being process by the IESG for
operational aspects.  These comments are to aid the authors and the NM/OPS Area
Directors.  The document editors and the WG chairs hsould treat these comments
as any other last call comments.

Status: ready,  with  2 operator questions and 1 yang question.  The question
are just things to think about for the authors and ADS.

Questions:

The documentis readable and aligns with RFC7683 and
draft-ietf-dime-agent-overload.     The language in this document also aligns
with language in the SIP Overload Control (SOC) document [RFC7415].

As I am not familar with current DIAMETER deployments, i've got a few
operational questions for the authors to consider:

1)  If a operator where deploying this new algorithm,
   what type of deployment considerations would
    be necessary?   Should certain topologies
    of Diameter deployments utilize certain
   overload algorithms?

 2) What failure modes will the operator see
   in the current overload abatement that
   would encourage the operator to
   spend the effort to go to this new DOIC
   rate limit?

As a researcher and implementer, sections 1 and  7 were sufficient
to answer these questions.   However,  I would ask the authors,
WG chairs, and OPS/NM ADs to determine if these are sufficient
for the normal operators.
SRD> We had multiple operators involved in the development of this draft, in fact, one of the authors works for an operator.  As such, I'm confident that their concerns have been addressed.

Question 3:  Just for my own understanding,
is there a plan to control DIAMETER protocols with YANG
modules?
SRD> Not to my knowledge.


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

--------------0EB645FECEC4AC41C06D9EEC-- From nobody Tue Jan 29 13:34:24 2019 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0A8130FFE for ; Tue, 29 Jan 2019 13:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com 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 1ZVdyzNPde1f for ; Tue, 29 Jan 2019 13:34:20 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5E7C2130ED7 for ; Tue, 29 Jan 2019 13:34:20 -0800 (PST) Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0TLYH3T086228 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 29 Jan 2019 15:34:19 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1548797659; bh=RKbC8MLYbnQZ6tIa5r4AXM1Tdk/ckgXthugJ6E8QZGw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=SNU8gkHtPWv4nd5AjPRhgPHy2Rd0NdBaY9oOFqsoRxmyDPALFxiMa/aKXbkj9ShjA yugLo6tSZ2U1vqN9yGdC9BN5HjL/xwvNs7JYRM4nlNnG1Glcxxh7oBPPllk9R+14Yw 8z6FM61HJQwgdkobVIxbZK7HfA3wLyS141Ms92gc= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_080FCC15-A8F5-4BEF-A6FC-904F2D4F7832"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 29 Jan 2019 15:34:15 -0600 In-Reply-To: Cc: dime@ietf.org To: Steve Donovan References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Dime] AD Evaluation of draft-ietf-dime-doic-rate-control-10 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jan 2019 21:34:23 -0000 --Apple-Mail=_080FCC15-A8F5-4BEF-A6FC-904F2D4F7832 Content-Type: multipart/alternative; boundary="Apple-Mail=_2AB8577B-C3B3-4BDA-BFE9-FFE794061EEA" --Apple-Mail=_2AB8577B-C3B3-4BDA-BFE9-FFE794061EEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That all looks good, thanks! Ben. > On Jan 24, 2019, at 5:07 PM, Steve Donovan = wrote: >=20 > Ben, >=20 > I've updated the document based on our comments. See more below. >=20 > Steve >=20 > On 12/21/18 5:06 PM, Ben Campbell wrote: >> Hi, >>=20 >> This is my AD evaluation for draft-ietf-dime-doic-rate-control-10. I = previously reviewed version 8, however since some time has passed I = reviewed this version =E2=80=9Cfrom scratch=E2=80=9D. >>=20 >> In general the draft is in good shape. I think it=E2=80=99s ready for = IETF Last Call, which I will request shortly. Please note the last call = window will be extended due to the upcoming holidays. >>=20 >> I have a few minor comments that can be resolved along with any last = call feedback. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> ------------------------------------- >>=20 >> =C2=A74, paragraphs 2 and 3: Am I correct to assume that, as new DOIC = algorithms get added, nodes could support both of these and something = else? If so, then in paragraph 2 I suggest s/ =E2=80=9C support both the = loss and rate based abatement algorithms=E2=80=9D/ "support at least the = loss and rate based abatement algorithms=E2=80=9D > SRD> No, only loss is required to be supported. The statement is = that, because loss is always required, supporting rate implies = supporting loss and rate. I don't think a change is required here. >>=20 >> ..... and in paragraph 3, I suggest adding something to the effect of = =E2=80=9C... and MAY indicate support for others.=E2=80=9D > SRD> I agree this is a good change. >>=20 >> (nit) =C2=A75.5, 2nd paragraph: "It is also possible for the = reporting node to send overload >> reports with the rate algorithm indicated when the reporting node >> is not in an overloaded state.=E2=80=9D >>=20 >> I suggest s/ =E2=80=9Cindicated when=E2=80=9D / =E2=80=9Cindicated = even when=E2=80=9D > SRD> Okay. >>=20 >> (nit) =C2=A75.6, first paragraph: The algorithm is detailed in 7.3. >=20 >>=20 >> =C2=A77.3.1: "To apply abatement treatment to new Diameter requests = at the rate >> specified in the OC-Maximum-Rate AVP value sent by the reporting node >> to its reacting nodes, the reacting node MAY use the proposed default >> algorithm for rate-based control or any other equivalent algorithm >> that forward messages in conformance with the upper bound of 1/T >> messages per second.=E2=80=9D >>=20 >> This is redundant to similar normative text in =C2=A75.6. I suggest = keeping just one (probably this one since it=E2=80=99s more precise) and = use descriptive language for the other. > SRD> Okay, I changed 5.6 to the following: >=20 > When determining if abatement treatment should be applied to a > request being sent to a reporting node that has selected the rate > overload abatement algorithm, the reacting node can choose to > use the algorithm detailed in Section 7. >>=20 >>=20 >> =C2=A79: Do the authors think that the rate algorithm might be more = effective at DoS mitigation than the loss algorithm? If so, that might = be worth a mention in the security considerations. > SRD> Good suggestion. I've added the following paragraph to the = security section: >=20 > In addition, the rate algorithm could be used to handle DoS attacks = more effectively than the loss algorithm. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime = >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_2AB8577B-C3B3-4BDA-BFE9-FFE794061EEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That = all looks good, thanks!

Ben.

On Jan 24, 2019, at 5:07 PM, = Steve Donovan <srdonovan@usdonovans.com> wrote:

=20 =20
Ben,

I've updated the document based on our comments.  See more = below.

Steve

On 12/21/18 5:06 PM, Ben Campbell wrote:
Hi,

This is my AD evaluation for draft-ietf-dime-doic-rate-control-10. I =
previously reviewed version 8, however since some time has passed I =
reviewed this version =E2=80=9Cfrom scratch=E2=80=9D.

In general the draft is in good shape. I think it=E2=80=99s ready for =
IETF Last Call, which I will request shortly. Please note the last call =
window will be extended due to the upcoming holidays.

I have a few minor comments that can be resolved along with any last =
call feedback.

Thanks!

Ben.

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

=C2=A74, paragraphs 2 and 3: Am I correct to assume that, as new DOIC =
algorithms get added, nodes could support both of these and something =
else? If so, then in paragraph 2 I suggest s/ =E2=80=9C support both the =
loss and rate based abatement algorithms=E2=80=9D/ "support at least the =
loss and rate based abatement algorithms=E2=80=9D
SRD> No, only loss is required to be supported.  The = statement is that, because loss is always required, supporting rate implies supporting loss and rate.  I don't think a change is required = here.
..... and in paragraph 3, I suggest adding something to the effect of =
=E2=80=9C... and MAY indicate support for others.=E2=80=9D
SRD> I agree this is a good change.
(nit) =C2=A75.5, 2nd paragraph: "It is also possible for the reporting =
node to send overload
reports with the rate algorithm indicated when the reporting node
is not in an overloaded state.=E2=80=9D

I suggest s/ =E2=80=9Cindicated when=E2=80=9D / =E2=80=9Cindicated even =
when=E2=80=9D
SRD> Okay.
(nit) =C2=A75.6, first paragraph: The algorithm is detailed in =
7.3.

=C2=A77.3.1: "To apply abatement treatment to new Diameter requests at =
the rate
specified in the OC-Maximum-Rate AVP value sent by the reporting node
to its reacting nodes, the reacting node MAY use the proposed default
algorithm for rate-based control or any other equivalent algorithm
that forward messages in conformance with the upper bound of 1/T
messages per second.=E2=80=9D

This is redundant to similar normative text in =C2=A75.6. I suggest =
keeping just one (probably this one since it=E2=80=99s more precise) and =
use descriptive language for the other.
SRD> Okay, I changed 5.6 to the following:

   When determining if abatement treatment should be = applied to a
   request being sent to a reporting node that has = selected the rate
   overload abatement algorithm, the reacting node can = choose to
   use the algorithm detailed in Section 7. 
=C2=A79: Do the authors think that the rate algorithm might be more =
effective at DoS mitigation than the loss algorithm? If so, that might =
be worth a mention in the security considerations.
SRD> Good suggestion.  I've added the following paragraph to = the security section:

   In addition, the rate algorithm could be used to handle = DoS attacks more effectively than the loss algorithm.




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

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

= --Apple-Mail=_2AB8577B-C3B3-4BDA-BFE9-FFE794061EEA-- --Apple-Mail=_080FCC15-A8F5-4BEF-A6FC-904F2D4F7832 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlxQxtcACgkQgFZKbJXz 1A0iyw//Wbv+Wikmbt3wKGL9YWeIkkl23l6saEaB03FXi4BH17d/bvXaEQ1ZjUeA nBUyB+0ydk3zKkNaSO0Hf1CznhAGYWy+8LFQZZBd+Q2oaJ/nRMboeHDk4qWTCMdN QHW8TL2DmKyKBpOn05vKr2Wk93u3TUB5VFjgkJ031o1Qiypnxy3UyVeACldf4dsH DsMgbI/rbQf8WJsHUcDwWJEUkboMh7wrJ6LI63RB/wQ1mBXii1I+srySEl002Ewd uRdiVw0XtOMCCZU8O7cpk9Xjs+0nNZI3To+8jY8F+D1FyvFy8DoguYkuzAcAZg2h WmRjYfsXjii3QgF8f86KYZZXnBU3BhnyZ7VqKa/PKQmOG+3wQ9YfeRTO9bg9tIru O3tHQZfa/RHy65dm/MyYakl6uSPRtL0Pn/lwEfJikWFxMchU7NzVa8yNv3eYkpB7 o9ALKONawhaXXqRA5HuLxaZVCsjJc+yn4XG5TWLyB5s38vAiNblvS9PH1h8B5nJa COLVWU2bvDtnN0A+xBm38luZjrrJuN00ooZq0CnJDrU8N5vqej0BpjNWLAm6Hax7 bUzSHptkeIlOr2oXo/mWChtDMD2DZLDdJ1fu5QlOrFzJ5ttX+/MH3p8ui7zk1zdd vVK0SJzJ5YQ7YFecLk0WbA47+jXAP8nGASNl8xtquCPLwAmX25c= =R6X9 -----END PGP SIGNATURE----- --Apple-Mail=_080FCC15-A8F5-4BEF-A6FC-904F2D4F7832--