Re: [Dots] Improve controllability and predictability of keepalives

Thank you, Carsten!

Regards,
Valery.

> Thank you.
> 
> I think my concerns are addressed.
> 
> Grüße, Carsten
> 
> 
> > On Nov 20, 2019, at 14:50, <mohamed.boucadair@orange.com>
> <mohamed.boucadair@orange.com> wrote:
> >
> > Hi Carsten,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Carsten Bormann [mailto:cabo@tzi.org] Envoyé : mercredi 20
> >> novembre 2019 07:20 À : BOUCADAIR Mohamed TGI/OLN Cc :
> dots@ietf.org
> >> 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
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots