Re: [Tools-discuss] Asynchronous submission

Carsten Bormann <cabo@tzi.org> Tue, 30 May 2023 14:48 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0137DC14CF15 for <tools-discuss@ietfa.amsl.com>; Tue, 30 May 2023 07:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Inn2PVhoZI9A for <tools-discuss@ietfa.amsl.com>; Tue, 30 May 2023 07:48:44 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7D9C1526E9 for <tools-discuss@ietf.org>; Tue, 30 May 2023 07:48:42 -0700 (PDT)
Received: from [192.168.217.124] (p548dc0f6.dip0.t-ipconnect.de [84.141.192.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4QVwJ802jyzDCdB; Tue, 30 May 2023 16:48:39 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <b375b834-33d2-bd23-53f4-1054d2f5758e@staff.ietf.org>
Date: Tue, 30 May 2023 16:48:39 +0200
Cc: tools-discuss@ietf.org
X-Mao-Original-Outgoing-Id: 707150919.496509-2055ae39f4a4dfcd426f710677e4ea2a
Content-Transfer-Encoding: quoted-printable
Message-Id: <11F879E6-613A-4781-9C36-28C4CDFA7C36@tzi.org>
References: <E5FE4F29-B372-4191-8BC9-DDF8545DEC0D@tzi.org> <b375b834-33d2-bd23-53f4-1054d2f5758e@staff.ietf.org>
To: Jennifer Richards <jennifer@staff.ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/Sipvs0UjUYUVoEYZ6h9fDn4DNas>
Subject: Re: [Tools-discuss] Asynchronous submission
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 May 2023 14:48:50 -0000

On 2023-05-30, at 15:50, Jennifer Richards <jennifer@staff.ietf.org> wrote:
> 
> There's an existing API endpoint for checking the draft status that we should use to improve the update strategy.
> 
> https://github.com/ietf-tools/datatracker/issues/5714

Thanks for opening that issue.

The refresh wait should be way shorter, 2 or 3 seconds.

If the concern is that the server might be loaded by the refreshes, the refresh wait should really be extended based on the server queue size, not on the status of the draft’s processing.
Using the API to check first might reduce the impact of a failing refresh request by an order of magnitude (but then, it *adds* a request for a succeeding one), but not really enough to cover the 100x impact of a last-minute-submit frenzy that we regularly have three times per year.

Grüße, Carsten