Re: [Dots] Behavior when keep-alives fail (RE: Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

Mirja Kuehlewind <> Thu, 12 December 2019 16:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A6041209D4; Thu, 12 Dec 2019 08:55:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 14hfnsIktAfU; Thu, 12 Dec 2019 08:55:37 -0800 (PST)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DE411209CC; Thu, 12 Dec 2019 08:55:37 -0800 (PST)
Received: from [] (helo=[]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ifRkV-00062B-FH; Thu, 12 Dec 2019 17:55:35 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330313E9A1B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Thu, 12 Dec 2019 17:55:33 +0100
Cc: "" <>, Benjamin Kaduk <>, "" <>, "" <>, The IESG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <787AE7BB302AE849A7480A190F8B93302EAB2ABA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93302EAB2CC5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93302EAB2F77@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <06e901d531a8$38f38d90$aadaa8b0$> <> <072901d531d3$bdd39c00$397ad400$> <> <> <787AE7BB302AE849A7480A190F8B93302F643236@OPEXCNORMAE.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B9330313E9A1B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3445.104.11)
X-HE-SMSGID: 1ifRkV-00062B-FH
Archived-At: <>
Subject: Re: [Dots] =?utf-8?q?Behavior_when_keep-alives_fail_=28RE=3A___Mirja?= =?utf-8?q?_K=C3=BChlewind=27s_Discuss_on_draft-ietf-dots-signal-channel-3?= =?utf-8?q?1=3A_=28with_DISCUSS_and_COMMENT=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Dec 2019 16:55:39 -0000

Hi Med,

See below.

> On 12. Dec 2019, at 09:12, wrote:
> Hi Mirja,
> Thank you for the feedback. 
> Please see inline. 
> Cheers,
> Med
>> -----Message d'origine-----
>> De : Mirja Kuehlewind []
>> Envoyé : mercredi 11 décembre 2019 15:42
>> Cc :; Benjamin Kaduk; dots-
>>;; The IESG
>> Objet : Re: [Dots] Behavior when keep-alives fail (RE: Mirja Kühlewind's
>> Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
>> Hi Med, hi all,
>> Just restarting the thread from here but based on the latest version that
>> was submitted (-39). Thanks a lot for the update and the additional work
>> you put in the draft as well as implementation! Really happy to see that
>> you found a solution and that is works!
>> I think I’m ready to resolve my discuss just two more minor questions on
>> the new wording in the draft. However, I don’t think there are any
>> remaining technical issues and we might just ned to make sure the wording
>> is clear.
>> Ben pinged me already about this part:
>> "Mitigation requests MUST NOT be delayed
>> because of other congestion control checks.  Typically, mitigation
>> requests must be sent without checks on probing rate (Section 4.7 of
>> [RFC7252]).”
>> My understanding right now is that there anyway can only be one active
>> mitigation request at a time…?
> [Med] Exactly. One mitigation request for a mitigation scope is allowed. The authoritative behavior is: 
>   DOTS agents MUST NOT send more than one UDP datagram per round-trip
>   time (RTT) to the peer DOTS agent
> and
>   If the DOTS client cannot maintain an RTT estimate, it MUST
>   NOT send more than one Non-confirmable request every 3 seconds, and
>   SHOULD use an even less aggressive rate whenever possible
> The excerpt you quoted is a guard against delaying a mitigation request because, e.g., of a very low probing-rate. We want to make sure that the first mitigation is sent as soon as possible. 
> The two guards we have for this are discussed in Slide 8 of 

Great this is all fine. I still think the wording in these sentences is confusing as it says "other congestion control checks”. Given this is already well defined, can we maybe just removed those two sentences (in order to avoid similar confusion as I had for the reader)?

> If that is the case please note this
>> explicitly here because that inherently limits the “rate" at which
>> mitigation request can be sent.
> [Med] This is mentioned in the sentence right before the one you quoted. 
> However, I also don’t really understand
>> what the two sentences above are meant to say. I looked again at section
>> 4.7 of RFC7257 and am not sure what you are referring to. Can you
>> explain/clarify?
> [Med]  As explained above, we are referring to the probing-rate behavior in 4.7 RFC7252:
>   The specific algorithm by which a client stops to "expect" a response
>   to a Confirmable request that was acknowledged, or to a Non-
>   confirmable request, is not defined.  Unless this is modified by
>   additional congestion control optimizations, it MUST be chosen in
>   such a way that an endpoint does not exceed an average data rate of
>   PROBING_RATE in sending to another endpoint that does not respond.
>> Later on there is this sentence:
>> “The DOTS client MUST then try to resume the (D)TLS session.”
>> Does it say anywhere in the document how often/how long it should retry? I
>> think nevertheless we need some kind of termination condition here are
>> retrying to infinity doesn’t seem the “best” approach.
> [Med] This is left to the implementation. Please note that we followed the same approach for when an old session expires (see for example, point #3 in this thread:

I was rather talking about the number of retries than an expiration time. E.g. one could say: "The DOTS client SHOULD try to reconnect RECON_NUM times with a default of RECON_NUM=5”
Do you think it would be possible to say anything like that?