[Dots] Improve controllability and predictability of keepalives

<mohamed.boucadair@orange.com> Tue, 12 November 2019 09:18 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 179F31201E3 for <dots@ietfa.amsl.com>; Tue, 12 Nov 2019 01:18:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8CrrOou7Zcfp for <dots@ietfa.amsl.com>; Tue, 12 Nov 2019 01:18:55 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1D4120046 for <dots@ietf.org>; Tue, 12 Nov 2019 01:18:55 -0800 (PST)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 47C2HK4sdwz5vkv; Tue, 12 Nov 2019 10:18:53 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 47C2HK31RGzyQl; Tue, 12 Nov 2019 10:18:53 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d%21]) with mapi id 14.03.0468.000; Tue, 12 Nov 2019 10:18:53 +0100
From: <mohamed.boucadair@orange.com>
To: "Carsten Bormann (cabo@tzi.org)" <cabo@tzi.org>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Improve controllability and predictability of keepalives
Thread-Index: AdWZOjG0GmH8bbOEScaak/2iE6U5+Q==
Date: Tue, 12 Nov 2019 09:18:53 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330313624A5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330313624A5OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/nYGHDXf61hM55SZ19qIwk8aNmzg>
Subject: [Dots] Improve controllability and predictability of keepalives
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2019 09:18:57 -0000

Hi Carsten,

You indicated the following in an offline message (I'm adding dots mailing list as you were OK; see below):

> I would have expected using requests sent in non-confirmable messages,

> requiring more work on the application side (interpreting losses) but also

> delivering a more regular, predictable, less noisy signal.

> A little bit of specification text is then needed to ensure that those

> requests/responses meet the requirements of RFC 8085 and the related

> specifications in RFC 7252, and that both sides are in a good position to

> interpret the signal they get.


> If not, I would like to discuss the issue on the DOTS mailing list, and see

> whether a small set of changes to the keepalive mechanisms employed can

> improve its controllability and predictability.

Assuming that non-confirmable application HBs are used, which changes do you think are needed to enhance the DOTS mechanism to meet 8085/7252 requirements?

As a reminder we do have the following for setting the hb parameters:

      Note: heartbeat-interval should be tweaked to also assist DOTS
      messages for NAT traversal (SIG-011 of [RFC8612]).  According to
      [RFC8085], keepalive messages must not be sent more frequently
      than once every 15 seconds and should use longer intervals when
      possible.  Furthermore, [RFC4787] recommends NATs to use a state
      timeout of 2 minutes or longer, but experience shows that sending
      packets every 15 to 30 seconds is necessary to prevent the
      majority of middleboxes from losing state for UDP flows.  From
      that standpoint, the RECOMMENDED minimum heartbeat-interval is 15
      seconds and the RECOMMENDED maximum heartbeat-interval is 240
      seconds.  The recommended value of 30 seconds is selected to
      anticipate the expiry of NAT state.

      A heartbeat-interval of 30 seconds may be considered as too chatty
      in some deployments.  For such deployments, DOTS agents may
      negotiate longer heartbeat-interval values to prevent any network
      overload with too frequent keepalives.

      Different heartbeat intervals can be defined for 'mitigating-
      config' and 'idle-config' to reduce being too chatty during idle
      times.  If there is an on-path translator between the DOTS client
      (standalone or part of a DOTS gateway) and the DOTS server, the
      'mitigating-config' heartbeat-interval has to be smaller than the
      translator session timeout.  It is recommended that the 'idle-
      config' heartbeat-interval is also smaller than the translator
      session timeout to prevent translator traversal issues, or
      disabled entirely.  Means to discover the lifetime assigned by a
      translator are out of scope.

Thank you.