[core] stateless --- advice on replay windows

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 26 October 2020 17:56 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03053A0E05 for <core@ietfa.amsl.com>; Mon, 26 Oct 2020 10:56:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 7Q8bTxoDCpHS for <core@ietfa.amsl.com>; Mon, 26 Oct 2020 10:56:10 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57783A100E for <core@ietf.org>; Mon, 26 Oct 2020 10:55:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B74A53899E for <core@ietf.org>; Mon, 26 Oct 2020 14:02:18 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QRC8Bqpv19bO for <core@ietf.org>; Mon, 26 Oct 2020 14:02:18 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 51B603899D for <core@ietf.org>; Mon, 26 Oct 2020 14:02:18 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 193C8493 for <core@ietf.org>; Mon, 26 Oct 2020 13:55:43 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: core@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 26 Oct 2020 13:55:43 -0400
Message-ID: <8681.1603734943@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Rzxaf6UhMu6IERaUoCT78FBEZmY>
Subject: [core] stateless --- advice on replay windows
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2020 17:56:13 -0000

In pull request:
   https://github.com/core-wg/stateless/pull/11/files#diff-cf7b3529858e66fcec2a75824b625d78d48be9aec680e404c6ed6aa3e4bfce0fR909

At line 901:
   https://github.com/core-wg/stateless/pull/11/files#diff-cf7b3529858e66fcec2a75824b625d78d48be9aec680e404c6ed6aa3e4bfce0fR909

I suggest:

        <t>
          This size of the replay window depends upon the number of
          outstanding requests that need to be outstanding.  This can be
          determined from the rate at which new ones are made, and the
          expected duration in which responses are expected.
        </t>

        <t>
          For instance, given a CoAP ACK_TIMEOUT of 2s, and a request rate of
          10 requests/second, any request that is not answered within 2s will
          be considered to have failed.  Thus at most 20 request can be
          outstanding at a time, and any convenient replay window larger than
          20 will work.  As replay windows are often implemented with a
          sliding window and a bit, the use of a 32-bit window would be
          sufficient.
        </t>

I am looking for some review of this text as to sanity.
Is it good advice?  are my assumption reasonable?

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide