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, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind [mailto:[e-mail]]
> Envoyé : jeudi 12 décembre 2019 17:56
> À : 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,
> 
> See below.
> 
> > On 12. Dec 2019, at 09:12, [e-mail] wrote:
> >
> > 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.
> 
> 
> Great this is all fine.

[Med] Great. 

 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)?
> 

[Med] In order to have the guard enforced by the protocol, we can make with the following change:  

OLD: 
   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]).

NEW:
   Mitigation requests MUST NOT be delayed because of checks on
   probing rate (Section 4.7 of [RFC7252]). 


> >
> >
> > 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)
> 
> 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?
> 

[Med] I don't think we need to define a retry logic at the DOTS layer given that DOTS relies upon the DTLS layer. 

DTLS layer will try sending ClientHello message multiple times till a timeout is reached: Please see https://tools.ietf.org/html/rfc6347#section-3.2.1 (ClientHello loss example) and https://tools.ietf.org/html/rfc6347#section-4.2.4.1. The number of retries will depend on the initial timer value. 

As discussed in 6347, timer values are implementation-specific.