Re: [httpapi] RateLimit Header client implementations

Darrel Miller <Darrel.Miller@microsoft.com> Tue, 05 January 2021 16:17 UTC

Return-Path: <Darrel.Miller@microsoft.com>
X-Original-To: httpapi@ietfa.amsl.com
Delivered-To: httpapi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845473A0E4C for <httpapi@ietfa.amsl.com>; Tue, 5 Jan 2021 08:17:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 geZFveDiq6ce for <httpapi@ietfa.amsl.com>; Tue, 5 Jan 2021 08:17:14 -0800 (PST)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650103.outbound.protection.outlook.com [40.107.65.103]) (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 282C33A0E05 for <httpapi@ietf.org>; Tue, 5 Jan 2021 08:17:13 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QikYvbTSmR/rQQPx92C3H+Di5tlHZy+NsUfrkGxTnlTW50+51cl3FSdHHvip70HZzAmA0Q+KF4zSuBwBIPL0Y8PxvDpGN0O8ksWEBpCidEqqdiMQCvFKhZDKHLF7ZJE0Eu2Qh3bZjjY9kFUo1t3t1rlG+RNryW0N/9aw2Xica1Lpvde9O3D3yhUQc3Qn2DN/LXmlvHmrPbWkyE1SLbIY3Q3g68OKty9yf21JYgycsjbX3wem/Mu2zRqeoLoA790iFh7QWqhx1aboabpWC1VVjbCcpg1UvquWRlZIKlfOFiUgzckeMxBmPDslMmze46asyK5QPqgKhk53guxv+IAF0g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PGrbGeDfJpYoIdK2GJ5vBJRs4/eoL0Qk/DkVSs/mvqU=; b=IZjyeUEUzd7Hfcjp31POLrIFkcd6y3YS5b7YqbgwaDK+KJWbZ1hRilSac8ND76+tmmVb1HsO2/WbjXC/Z8t+p3m8vdihQxRVW5CrCZpJMuZV0837AeFk6Oapu81I+eaTjrnbCjaQ2qs2VX0jVP2RFKS/Cyk8hsTajMKOb9CFX2xZtnHfzng7xvvILEwu3eijyBGeNFnElWQ/JrP9PnIJD/3tcPPW1tpqy05g50t7tS1vVqoUXLuKkNtE1rMlb5/CEvZFJcBLoyY33LK181VImZgdPJmYKoHFV+BxrfbNy2oNP8OiIf7Y7RZJG39WxJjknoPNrVyco3RJG4lw+68b5g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PGrbGeDfJpYoIdK2GJ5vBJRs4/eoL0Qk/DkVSs/mvqU=; b=MuSttvl7Z2zIZAJt8YvmEx82J6BOZS8/ChS8V34IakxFnF8utIfC8ntX89Vq2xfXcOYnvsOZgBIy3olnTUK+mKEPsaeqcWXbQFY4We7zN8WARws40OZm//Cs3IYvUpDwVSTYdZ2f7wDzH5fjVPTULkSdwLGz6haNGbC+cCufSuQ=
Received: from (2603:10b6:a03:1d9::20) by BY5PR00MB0840.namprd00.prod.outlook.com (2603:10b6:a03:1d7::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3775.0; Tue, 5 Jan 2021 16:17:04 +0000
Received: from BY5PR00MB0837.namprd00.prod.outlook.com ([fe80::dd10:ecf5:45f7:b6f4]) by BY5PR00MB0837.namprd00.prod.outlook.com ([fe80::dd10:ecf5:45f7:b6f4%4]) with mapi id 15.20.3779.000; Tue, 5 Jan 2021 16:17:04 +0000
From: Darrel Miller <Darrel.Miller@microsoft.com>
To: "amr@redhat.com" <amr@redhat.com>, "darrel@tavis.ca" <darrel@tavis.ca>, "httpapi@ietf.org" <httpapi@ietf.org>
CC: "robipolli@gmail.com" <robipolli@gmail.com>
Thread-Topic: [httpapi] RateLimit Header client implementations
Thread-Index: AQHW3lKxGhpPRJVD8kOy66GCWE4TNKoXg/eAgAGy0so=
Date: Tue, 05 Jan 2021 16:17:04 +0000
Message-ID: <BY5PR00MB0837209B7CFF3687EFCD1580F0D19@BY5PR00MB0837.namprd00.prod.outlook.com>
References: <DM6PR01MB49370264EE9621D603FEAA81A3D70@DM6PR01MB4937.prod.exchangelabs.com>, <CALmQWfiw+1DJ20=3A5JYNVziS9zvttEOTNFuEZE2y83AbZSrYQ@mail.gmail.com>
In-Reply-To: <CALmQWfiw+1DJ20=3A5JYNVziS9zvttEOTNFuEZE2y83AbZSrYQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-01-05T16:17:04.650Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;
authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [74.15.147.35]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: c47e0eeb-b380-4bc0-1da7-08d8b195577f
x-ms-traffictypediagnostic: BY5PR00MB0840:
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: <BY5PR00MB084066936C834465C3855A3FF0D19@BY5PR00MB0840.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: teXG5euyJVSLdBoA1unEi0tmm9mNriW5p5QA6q5iihewZtHplVZTb+FlhUM9fhlw8Ib/H5PkBH1eBLUCDk3YmNdrScvU8uQG69FpobSQcnPCkH0V9iQWJn6TU0X5pb2PUfcUM0NqzhPDPD1jVhor+NRdItJ/kb6ghgXXmrc9GD2IPjcYly6szaWiIswjqiQI10PDzledWW27zlDo7FFLcOSqb3WRXMhRQa9BPDd8HepZtwXDUa13dD/AMrgAgQaJC9FBbfcqsrJdDuu5Vf7ofwpGSNy03TmiIMFDYJ4vMGx+gTuEr/27yUflGJ+mC13f+tjZWBmaHMoAtQ768/QqQvjRI+PVs13HRBt8k32CFsxt6dryztVQAudXsoxT3DxByLGF4jFHb2SFwmvBgFtQHg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR00MB0837.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(498600001)(83380400001)(2906002)(110136005)(5660300002)(8936002)(82960400001)(82950400001)(26005)(6506007)(66946007)(10290500003)(4326008)(76116006)(66476007)(64756008)(66446008)(7696005)(8990500004)(66556008)(55016002)(52536014)(8676002)(9686003)(53546011)(71200400001)(33656002)(86362001)(186003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: ia9tpvZC8edu0gyY/frO+I7Ev56W18WxFF3ZXzJB0Jlvolp1/JVX//+GKB/0UbCTMij2dUAoWBke0lXziM4zC7XM8FgeTZVX3diArddESv8QhegSYlUG12Edux9OF4dkH0t7PbFEK6bCtozJ+BAlwucbE1vjZJdhVDJ6YzYDjqdVQkEwQkKoUc4L3089Qaf2QJSQOPUg1WgG+XeA5+/Bm28JqQ+LIdxolWg6N3WDElVoNF7M0ay1zKGj/Q86/9QrTrxhLKtqgSykkQKW/wCY9pDLTtjnQDsyP2tZEi94DIFYiLyuj+YEwkk30Y8XDNWEml4ZhN6yOXYNaP0HkoBf5wXEqWolWf7DnHn1OMKDoT1AX5J1+JqtKdkcLTRajbbYqAkAQy+mF0JeX30Z3r6P4bS4EYdt8W15pFl4r9Wo3GHKcK8UEbaPVQpADKx1/+xduzrGvlGHXuZH7rL+A52haJzfGxPbjTSv0zAxNWt9kuRZxiVs4ANCnZ+ocvaOnjV+54bA4RXIp0rCPvF3gFgIMXebIggrBM8uqMDSOPWbeAvajw/HqAMwHsR1i7yeyHRYmXlSpYxGDsU2GtAyFXTV9rJHfC8uUXyVeJkEL6Be8BKTisSf0uAku5xPCjqBSA7xQ3oVuyJprY7fT3/ev+NZ2itV1sclB6UomO3qT3M1g41abcwekbB1ggqLnaogSQjR2aR5XvMpd8qjaqsdqHJYT3V1yq4AYykQcSiWSSrzrQ2v9LoenY4OPJbff2NBICMtJqAPRkpUFfHV/WJwfbbPK66USQsFF9PWOXFIaqnbU0r9+EmLMk0rW1CX4gqbSIeehdtyOvB9HOTFvvcBjGsywQJ0GnVx+yZzdjpQjrxaABxakUdWyW4LZiw4beRZlC8h5FinP+ZHsDQ9J3jJm6qLSxVvVon5nk2Cio8EgVYNbfYTyvHyg4csEWE63sW+bhCw3l5JtwCZuryo5VRgGPa10LLelcIfOE8SkxjC9DyxUpSsQPdTCbg+Jn6hzIkoIJ5rByOnfw52cbT01FEYTGHQExlQernbLslJ2x5XKznw8JJvChlaX0MM2gXSAmN6zxyQ
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR00MB0837.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c47e0eeb-b380-4bc0-1da7-08d8b195577f
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2021 16:17:04.7862 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tavM6rCuI82nuuMxLFvLkKwD0Hbhs+idM18VroEeKvvNFX8bxsb/H6XkZvxL2QhIEtikESqRUjq3QRdfUCRA6w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR00MB0840
Archived-At: <https://mailarchive.ietf.org/arch/msg/httpapi/bYO9XFBL7JrYY0uWZ-J0UAJuzfM>
Subject: Re: [httpapi] RateLimit Header client implementations
X-BeenThere: httpapi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Building Blocks for HTTP APIs <httpapi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/httpapi>, <mailto:httpapi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/httpapi/>
List-Post: <mailto:httpapi@ietf.org>
List-Help: <mailto:httpapi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpapi>, <mailto:httpapi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2021 16:17:16 -0000

Hey Alex,

> From: httpapi <httpapi-bounces@ietf.org> on behalf of Alex Martinez <amr@redhat.com>
> Hi Darrel,
>> On Wed, Dec 30, 2020 at 3:17 AM Darrel Miller <darrel@tavis.ca> wrote:
[...] 
>>  ... 
>>  Enable user agents to avoid hitting rate limit due to some kind of punitive behavior.
>>  

> The scenario about "hitting rate limiting" is quite broad in scope. You can have rate limits
>  apply per API endpoint, per user identity, per connection, per time of day, per infrastructure 
> resources, or even per service type or cost, or a combination of them all - which is quite a
>  bit more than just limiting some misbehavior.

Sorry, I wasn't clear.  I completely understand the variety of ways that API providers need to limit excessive behavior by clients.  I was meaning something different.  Some API providers we go beyond simply returning a 429 and a retry-after header to slow down the consumer.  They will "punish" the client for reaching the limits. Some services will "tarpit" the client by deliberately slowing the response down.  I believe Roberto mentioned about some services dropping the connection.  

My assertion is that if we discouraged API providers from punishing consumer for reaching a rate limit, and we promote the use of the retry-after as a signal to the client to back-off before making another call, then there are fewer scenarios where a client is required to constantly monitor "the number of calls left before reaching the limit".  Returning and monitoring "calls remaining" is potentially an expensive operation, especially when multiple clients can consume the same quota, e.g. in the case of calls per user that is using multiple applications.

> The immediate benefit of these headers to service providers is being able to signal expectations 
> to clients so they can adapt.

The question I have is with the existing non-standard headers, how many people have actually bothered to write this adaptive client code?  Do we believe that lack of standardization has been sufficient to discourage people from writing that code?  Are the only people writing that code the ones who are trying to avoid punitive behavior?  If so, maybe a best practices document that recommends not doing that would be more constructive.

>  Sometimes it is just a matter of adjusting to some specific rate of 
> resource consumption. Some other times the only way to adapt is just to stop using a service 
> entirely for a while or use another endpoint, and that's more useful than just returning a 403 
> or 50X without further information, ie. during a maintenance window you can use the headers 
> to signal that window with 0 quota units and avoid useless traffic.

Why would a 503 with a retry-after header with a period that matches the maintenance window not be sufficient here?

Darrel