Re: [Dime] New version of DOIC rate draft

Ben Campbell <ben@nostrum.com> Sun, 16 September 2018 05:44 UTC

Return-Path: <ben@nostrum.com>
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 021D01277D2; Sat, 15 Sep 2018 22:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham 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 dWuJVs_U_khG; Sat, 15 Sep 2018 22:44:33 -0700 (PDT)
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 AF3C712F18C; Sat, 15 Sep 2018 22:44:33 -0700 (PDT)
Received: from [10.0.1.95] (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 w8G5iRQk003151 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 16 Sep 2018 00:44:29 -0500 (CDT) (envelope-from ben@nostrum.com)
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.95]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <16FE21DA-469E-4923-B95F-2D72FD423364@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_C3D0BB3C-5548-4570-B58D-65751CA86C0B"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sun, 16 Sep 2018 00:44:25 -0500
In-Reply-To: <2923159ae5604bc195c0bd6c644ecd75@CSRBTC1EXM029.corp.csra.com>
Cc: "draft-ietf-dime-doic-rate-control.all@ietf.org" <draft-ietf-dime-doic-rate-control.all@ietf.org>, "dime@ietf.org" <dime@ietf.org>
To: "Gunn, Janet P (NONUS)" <janet.gunn@gdit.com>
References: <a7a5c833-427c-acd4-1502-675ce3c1bbac@usdonovans.com> <6725C490-0449-45BE-BF74-0B937D72CD96@nostrum.com> <2923159ae5604bc195c0bd6c644ecd75@CSRBTC1EXM029.corp.csra.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/nIBTl6_Z4gOPM_2LmvURl6HghY4>
Subject: Re: [Dime] New version of DOIC rate draft
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Sep 2018 05:44:36 -0000


> On Sep 15, 2018, at 8:31 PM, Gunn, Janet P (NONUS) <janet.gunn@gdit.com> wrote:
> 
> Just addressing the first point- deleted the rest
> 
> -----Original Message-----
> From: DiME <dime-bounces@ietf.org> On Behalf Of Ben Campbell
> Sent: Saturday, September 15, 2018 7:57 PM
> To: draft-ietf-dime-doic-rate-control.all@ietf.org
> Cc: dime@ietf.org
> Subject: Re: [Dime] New version of DOIC rate draft
> 
> Substantive Comments:
> 
> - General: I still think more discussion is needed about allocating rate to multiple input sources. I get that the actual allocation is a matter of local policy, but there’s still implications that need discussion. I’m not sure I got my concern across in previous discussion, so here’s another attempt:
> 
> The issue I think needs elaboration on is how the offered load varies with the number of sources times the (average) rate per each source. That is, if the number of sources changes, the reacting node may need to change the rate limits assigned to each existing source.
> 
> As a hypothetical example, lets assume a reporting node wants to limit its entire offered load to 1000 tps. Further assume it has 10 active reacting nodes (all supporting the rate algorithm). Local policy is to allocate the rate limit equally across sources. So it sends an OLR to each of those clients to give it a rate limit of 100 tps. Now, if another 10 reacting nodes become active, it needs to reallocate the load across all 20, giving each a limit of 50 tps. Now, if some of those reacting nodes go off-line, or simply reduce their activity beneath the limit for an extended period of time, the reporting node may need to increase the allocation to the remaining nodes.
> 
> This is a fairly fundamental difference between rate and load; rate uses absolute numbers while load uses percentages.
> 
> <JPG> I am not sure if it is as fundamental a difference  as you think. (in both cases assuming each node has a relatively stable  load.)
> If there are 10 active reacting nodes, it asks each node to reduce its traffic to  (say) 50%.
> If 10 more nodes become active, it will need to ask each node to reduce its traffic to 25%
> If some of those nodes go offline, or reduce their traffic, it will increase the (percentage) allocation to each remaining node.
> 
> The "fundamental" difference is when each node has a fluctuating, unstable, load.
> Under "load" a node which currently has a small load needs to cut its traffic by the SAME percentage as the node which currently has a large load.
> Under "rate" a node which currently has a small load does NOT need to cut its load while the node which currently has a large load DOES need to cut its load.</JPG>
> 

Hi,

There can be more than one fundamental difference :-)

I wasn’t talking about how clients behave, I was talking about how the server expresses it’s intention. If a server wants to reduce the current load by half using the loss algorithm, it doesn’t need to know how many clients there are. Of course, it may have to keep adjusting the percentage if the offered load is not stable. OTOH, If it wants to reduce the load to a specific rate using the rate algorithm, it does need to know many clients there are.

 I’m not saying this is a flaw in any way. I agree that in many cases an absolute TPS value may be more useful than a relative value. I’m just saying the draft should talk about it.

Thanks,

Ben.