Subject: Re: [core] #394 (coap-tcp-tls): Ping/pong

From: "core issue tracker" <[email-masked]>
Date: Fri, 10 Jun 2016 19:30:16 -0000

#394: Ping/pong

Comment (by [email-masked]):

 Keep alive is better done through empty messages.

 Ping/pong is mainly requested by people who want to know whether their
 previous messages have been processed by the application layer on the
 other side.  It does not really have that semantics, but at least can find
 out whether the TCP data went through.  Because of difficulties with flow
 control implementations (see question number 3 in #393), this may be a
 fundamentally not quite right but still rather expedient solution.

 (Ping/pong could be invested with application layer custody semantics,
 either through an additional option or always.)

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-coap-tcp-
  [email-masked]         |  [email-masked]
     Type:  protocol     |      Status:  new
  enhancement            |   Milestone:
 Priority:  minor        |     Version:
Component:  coap-tcp-    |  Resolution:
  tls                    |
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/394#comment:2>
core <https://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Sat, 11 Jun 2016 13:20:33 -0000

#394: Ping/pong

Comment (by [email-masked]):

 +1 for empty messages for keep-alives.

 +1 to also support a lightweight checkpointing, since we need a way to
 indicate when resources can be freed safely.

Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/394#comment:3>
core <https://tools.ietf.org/core/>

---

From: "weigengyu" <[email-masked]>
Date: Mon, 13 Jun 2016 10:49:07 +0800

Hi,

It needs clarification.

Is it aiming at keeping TCP connectiong alive?

The Ping/pong messages are CoAP messges while it is empty message, is it?
If yes, TCP will deliver some short data (a CoAP message) to its peer.

An alternative way is to use the means defined in RFC7828 'The 
edns-tcp-keepalive EDNS0 Option'.
Although RFC7828 only concerns DNS, i.e. the TCP at DNS client sends a 
keepalive option to its peer at DNS server,
this option could be use by CoAP over TCP.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: core issue tracker
Sent: Saturday, June 11, 2016 9:20 PM
To: [email-masked] ; [email-masked] ; 
[email-masked] ; [email-masked]
Cc: [email-masked]
Subject: Re: [core] #394 (coap-tcp-tls): Ping/pong

#394: Ping/pong

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Mon, 13 Jun 2016 12:21:32 +0000

Hi Gengyu

I am not sure if this resets the discussion to the beginning. A survey by Hannes showed that many middleboxes just drop keep-alives at TCP level. A check of implementations showed that applications usually have no way to control these keep-alives. Thus, the authors decided to provide a CoAP-level keep-alive.

Hannes, is ends-tcp-keepalive EDNS0 Option something new?
Gengyu, is it more than a specification, that is, does it work in the field?

Ciao
Matthias

> -----Ursprüngliche Nachricht-----
> Von: core [mailto:[email-masked]] Im Auftrag von weigengyu
> Gesendet: Montag, 13. Juni 2016 04:49
> An: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Betreff: Re: [core] #394 (coap-tcp-tls): Ping/pong
> 
> Hi,
> 
> It needs clarification.
> 
> An alternative way is to use the means defined in RFC7828 'The edns-tcp-
> keepalive EDNS0 Option'.
> keepalive option to its peer at DNS server, this option could be use by CoAP over
> TCP.
> 
> 
> Regards,
> 
> Gengyu WEI
> -------------------------+----------------------------------------------
> -------------------------+---
> -------------------------+----------------------------------------------
> -------------------------+---
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Jun 2016 14:06:50 +0100

Right; as the draft says, just about any transport (TCP, TLS, Websocket)
already has a keepalive; it just turns out those may be hard to reach
(or not working very well) in some implementations.

The very simple method of sending and then ignoring empty messages
should provide enough of a keepalive for most applications that need
just that and can't get it from transport.

Ping/pong really is more of an application-layer thing (in particular
with the custody option), so it is definitely not being replaced by
keepalive at any layer (transport or CoAP).

Right now people are doing ping/pong by designating a resource they post
to; this of course will continue to work -- it may just be too much work
in the general case to find the specific resource that has been
designated for this.  But it is useful to keep this in mind before
inventing too much to add to ping/pong -- specialized resources may be
much better for those more specialized purposes.

Grüße, Carsten

---

From: Michael Koster <[email-masked]>
Date: Mon, 13 Jun 2016 06:12:04 -0700

If this is done at the application layer, we could designate resources that perform the keep-alive + network watchdog as an application layer device management function. It could be a simple OMA style collection with the ping resource itself along with some appropriate timers and controls.

Michael

> On Jun 13, 2016, at 6:06 AM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Jun 2016 14:45:15 +0100

> If this is done at the application layer, we could designate resources that perform the keep-alive + network watchdog as an application layer device management function. It could be a simple OMA st…

Right, that's what I was trying to say in my last paragraph.

Is your intention here to say that we should get rid of the signaling
messages because we can do this through resources?

(We could always add /.well-known/pong or some such.)

(None of this takes away from making sure that empty messages can be
used for keepalives.)

Grüße, Carsten

---

From: Michael Koster <[email-masked]>
Date: Mon, 13 Jun 2016 06:52:42 -0700

I think an application layer only solution should be considered. It would allow application layer recovery, which it seems is the right place for this sort of thing; for example, the application knows how to recover from non-idempotent operations.

If using RD, the registration update works very well, since there is a well defined response for failures.

.well-known/ping seems like a good idea, as it would capture the request message (ping) and could trigger the issue of a reply (pong). 

 We may also want to configure a ping source and ping interval for sending, as well as a timeout threshold for detecting failures.

Best regards,

MIchael

> On Jun 13, 2016, at 6:45 AM, Carsten Bormann <[email-masked]> wrote:
> 
> Michael Koster wrote:

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Jun 2016 15:10:43 +0100

> I think an application layer only solution should be considered. It would allow application layer recovery, which it seems is the right place for this sort of thing; for example, the application kn…

Right.
(We have a terminology problem here; all this is at the application
layer.  We have the transfer layer (CoAP), which is split in the message
and the request/response layer, which we are now augmenting with a
signaling component.  I think you are saying "above the request/response
layer"; i.e., in terms of CoAP requests such as POST.)

> .well-known/ping seems like a good idea, as it would capture the request message (ping) and could trigger the issue of a reply (pong). 

If it is POSTed to, we just need to define what is supposed to be in the
response.

>  We may also want to configure a ping source and ping interval for sending, as well as a timeout threshold for detecting failures.

As in configuring the other side?
We normally use resources for such configuration info, but we could of
course also use a CSM message to keep this bound to the connection.
Interesting.

Grüße, Carsten

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Mon, 13 Jun 2016 16:13:56 +0000

Having lifeliness completely in the application has problems with interoperability again (LWM2M and OCF probably use different resources). Using /.well-known/ping sounds like a good tradeoff where the payload could add application-specific features on top of an interoperable mechanism. What we lose is a generic way for custody transfer / checkpointing, which was asked by many stakeholders, though...

> Von: Michael Koster [mailto:[email-masked]]
> Gesendet: Montag, 13. Juni 2016 15:53
> An: Carsten Bormann
> Cc: Kovatsch, Matthias (CT RDA NEC EMB-DE); [email-masked]; draft-ietf-core-
> [email-masked]; [email-masked]
> I think an application layer only solution should be considered. It would allow
> application layer recovery, which it seems is the right place for this sort of thing;
> for example, the application knows how to recover from non-idempotent
> operations.
> 
> .well-known/ping seems like a good idea, as it would capture the request
> message (ping) and could trigger the issue of a reply (pong).
> 
>  We may also want to configure a ping source and ping interval for sending, as
> well as a timeout threshold for detecting failures.
> 
> Best regards,
> 
> MIchael
> 
> >> If this is done at the application layer, we could designate resources that
> perform the keep-alive + network watchdog as an application layer device
> management function. It could be a simple OMA style collection with the ping
> resource itself along with some appropriate timers and controls.
> >

---

From: "weigengyu" <[email-masked]>
Date: Thu, 16 Jun 2016 17:31:26 +0800

Hi Matthias,

> A survey by Hannes showed that many middleboxes just drop keep-alives at 
> TCP level.
I am very appreciated Hannes' survey.
There is a problem when and how the middlebox decides to finishe a TCP 
connection.
It is known that a TCP segment with FIN would be intiated by its upper layer 
through TCP-socket.

> A check of implementations showed that applications usually have no way to 
> control these keep-alives.
> Thus, the authors decided to provide a CoAP-level keep-alive.
If it is, how could CoAP work well?
Does CoAP not work on the top of those middlebox?

Regards,

Gengyu WEI
-----原始邮件----- 
From: Kovatsch, Matthias
Sent: Monday, June 13, 2016 8:21 PM
To: weigengyu ; [email-masked] ; 
[email-masked] ; [email-masked] ; 
[email-masked] ; [email-masked]
Cc: [email-masked]
Subject: AW: [core] #394 (coap-tcp-tls): Ping/pong

Hi Gengyu

I am not sure if this resets the discussion to the beginning. A survey by 
Hannes showed that many middleboxes just drop keep-alives at TCP level. A 
check of implementations showed that applications usually have no way to 
control these keep-alives. Thus, the authors decided to provide a CoAP-level 
keep-alive.

Ciao
Matthias

> Ticket URL: 
> <https://trac.tools.ietf.org/wg/core/trac/ticket/394#comment:3>

---

From: "weigengyu" <[email-masked]>
Date: Thu, 16 Jun 2016 18:42:47 +0800

Hi Carsten,

> (or not working very well) in some implementations.

It may be the problem of CoAP/TCP or CoAP/TLS/TCP,
it seems not be a problem for CoAP over Websocket.
It is known that HTTP1.1 provide a means of long alive connection and 
Websocket adopts it.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Carsten Bormann
Sent: Monday, June 13, 2016 9:06 PM
To: Kovatsch, Matthias
Cc: [email-masked] ; [email-masked] ; 
[email-masked]
Subject: Re: [core] #394 (coap-tcp-tls): Ping/pong

MichaelRight; as the draft says, just about any transport (TCP, TLS, 
Websocket)
already has a keepalive; it just turns out those may be hard to reach
(or not working very well) in some implementations.

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Thu, 16 Jun 2016 18:47:37 +0800

Hi Michael,

It seems that a new mechanism of CoAP for long alive connection is being 
defined.
It is much like that in HTTP1.1 and Websocket.
Is it?

Regards,
Gengyu WEI
-----原始邮件----- 
From: Michael Koster
Sent: Monday, June 13, 2016 9:12 PM
To: Carsten Bormann
Cc: [email-masked] ; [email-masked] ; 
[email-masked]
Subject: Re: [core] #394 (coap-tcp-tls): Ping/pong

Michael

---

From: "core issue tracker" <[email-masked]>
Date: Wed, 29 Jun 2016 20:07:21 -0000

#394: Ping/pong

Changes (by [email-masked]):

 * owner:  [email-masked] =>
            [email-masked]
 * status:  new => assigned

Comment:

 '''Moved to https://github.com/core-wg/coap-sig/issues/3'''

-- 
---------------------------------+-----------------------------------------
 Reporter:  [email-masked]       |       Owner:  [email-masked]
     Type:  protocol             |      Status:  assigned
  enhancement                    |   Milestone:
 Priority:  minor                |     Version:
Component:  coap-tcp-tls         |  Resolution:
 Severity:  Active WG Document   |
 Keywords:                       |
---------------------------------+-----------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/394#comment:4>
core <https://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Wed, 29 Jun 2016 20:12:07 -0000

#394: Ping/pong

 * status:  assigned => closed
 * resolution:   => fixed

-- 
---------------------------------+-----------------------------------------
 Reporter:  [email-masked]       |       Owner:  [email-masked]
     Type:  protocol             |      Status:  closed
  enhancement                    |   Milestone:
 Priority:  minor                |     Version:
Component:  coap-tcp-tls         |  Resolution:  fixed
 Severity:  Active WG Document   |
 Keywords:                       |
---------------------------------+-----------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/394#comment:5>
core <https://tools.ietf.org/core/>