Re: [Dots] Improve controllability and predictability of keepalives

[<[e-mail]>]

Hi Carsten, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Carsten Bormann [mailto:[e-mail]]
> Envoyé : mercredi 20 novembre 2019 07:20
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [e-mail]
> Objet : Re: Improve controllability and predictability of keepalives
> 
> >> Thank you.
> >> I still have a few questions, but I think this looks very good.
> >>
> >> 4.4 says:
> >>           Mitigation requests MUST NOT be delayed
> >> 	   because of other congestion control checks.
> >> What might those be?
> >
> > [Med] A too low probing rate for example as indicated in the sentence
> right after that excerpt. There is a risk that mitigation requests are
> delayed (or that heartbeats are not sent which may lead to session liveness
> checks).
> >
> >
> >> (You don’t want to be in a situation where you send a ton of mitigation
> >> requests that are mostly dropped at the tail of a queue.)
> >>
> >
> > [Med] Yes, we don't that. The authoritative rule is as follows:
> >
> >   Requests marked by the DOTS client as Non-confirmable messages are
> >   sent at regular intervals until a response is received from the DOTS
> >   server.  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 (case 2 in
> >   Section 3.1.3 of [RFC8085]).
> 
> And if it can?

[Med] It does the following: 

   DOTS agents MUST NOT send more than one UDP datagram per round-trip
   time (RTT) to the peer DOTS agent on average ...

> 
> >
> >
> >> Before Figure 27, it says:
> >>
> >>           The PUT request used for DOTS heartbeat MUST NOT have a
> >> 	   'cuid', 'cdid,' or 'mid' Uri-Path.  Such PUT requests MUST NOT be
> >>
> >> 	   relayed by DOTS gateways.
> >>
> >> Why?  (And what should the DOTS gateways do instead?)
> >
> > [Med] Session loss detect and recovery is local to an agent and its
> immediate peer. Heartbeats are thus not relayed.
> 
> Ah, I was confused.
> Where is “DOTS gateway” defined?

[Med] It is defined in draft-ietf-dots-architecture-14#section-2.2.3: 

=====
   Traditional client/server relationships may be expanded by chaining
   DOTS sessions.  This chaining is enabled through "logical
   concatenation" of a DOTS server and a DOTS client.

   A DOTS gateway may be deployed client-side, server-side or both.  The
   gateway may terminate multiple discrete client connections and may
   aggregate these into a single or multiple DOTS sessions.

   The DOTS gateway will appear as a server to its downstream agents and
   as a client to its upstream agents, a functional concatenation of the
   DOTS client and server roles, as depicted in Figure 4:

                         +-------------+
                         |    | D |    |
         +----+          |    | O |    |         +----+
         | c1 |----------| s1 | T | c2 |---------| s2 |
         +----+          |    | S |    |         +----+
                         |    | G |    |
                         +-------------+
======

> I’m assuming this is not like a CoAP Proxy?
> It would need to expose the equivalent to /hb.

[Med] Yes, nevertheless the client does not need to assess the end-to-end connection, but only the one it uses to place its mitigation requests (it is not even aware about the existence of the ultimate server). Likewise, the server domain (includes both gw and server) does only need to assess if it can reach out a client to trigger. 

> 
> > We can update as follows:
> >
> > "This procedure occurs between a DOTS agent and its immediate peer DOTS
> agent. As such, this GET request MUST NOT be relayed by a DOTS gateway. The
> PUT request used for DOTS heartbeat MUST NOT have a ‘cuid', 'cdid,' or
> 'mid' Uri-Path."
> 
> This doesn’t quite address the above, though.
> 
> Grüße, Carsten