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

[<[e-mail]>]

Hi Mirja,

Thank you for the feedback. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind [mailto:[e-mail]]
> Envoyé : mercredi 11 décembre 2019 15:42
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [e-mail]; Benjamin Kaduk; dots-
> [e-mail]; [e-mail]; 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 https://datatracker.ietf.org/meeting/106/materials/slides-106-dots-dots-signal-channel-heartbeat-mechanism-update-00. 


 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: https://mailarchive.ietf.org/arch/msg/dots/pdiC4xsbQiaazm14hvdTLefcUeY)