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

From: "core issue tracker" <[email-masked]>
Date: Tue, 26 Apr 2016 12:47:36 -0000

#394: Ping/pong

Comment (by [email-masked]):

 Here is the story for adding keep-alive functionality to the CoAP over TCP
 document.

 After reaching out to folks measuring TCP usage I was told that the use of
 TCP keepalive messages is often unreliable since network operators deploy
 middleboxes, which suppress these messages.

 For this reason we are suggesting to add a ping/pong message to the CoAP
 over TCP document. Here is how this could look like.

 First, we define a new CoAP Method Codes (for the request) and CoAP
 Response Codes (for the responses). Let us give them new numbers, such as
 7.01 (for PING) and 7.02 (for PONG).

 Here is an example message exchange:
 {{{
                         Client              Server
                            |                  |
                            | <--- TCP --->    |
                            | Connection Setup |
                            |                  |
                            |   NON            |
                            | GET /temperature |
                            |   (Token 0x74)   |
                            +----------------->|
                            |                  |
                            |   NON [0x23bc]   |
                            |   2.05 Content   |
                            |   (Token 0x74)   |
                            |     "22.5 C"     |
                            |<-----------------+
                            |                  |
                            |      ......      |
                            |   time passes    |
                            |      ......      |
                            |                  |
                            |7.03 Ping         |
                            |(Token 0x7f)      |
                            +----------------->|
                            |                  |
                            |7.02 Pong         |
                            |(Token 0x7f)      |
                            |<-----------------+
                            |                  |
                            |  <--- TCP --->   |
                            |  Conn. Teadown   |
 }}}

 The PING packet would look as follows:

 {{{
     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      0x01     |      0xe1     |      0x7f     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Len   =    0 ------>  0x01
     TKL   =    1 ___/
     Code  =  7.01     --> 0xe1
     Token =               0x7f

            Figure: PING Encoding Example.
 }}}

 The PONG packet has the following structure:

 {{{
     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      0x01     |      0xe2     |      0x7f     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Len   =    0 ------>  0x01
     TKL   =    1 ___/
     Code  =  7.02     --> 0xe2
     Token =               0x7f

            Figure: PONG Encoding Example.
 }}}

-- 
-------------------------+-------------------------------------------------
 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:1>
core <https://tools.ietf.org/core/>

---

From: Julien Vermillard <[email-masked]>
Date: Tue, 26 Apr 2016 15:32:44 +0200

Why not simply using CoAP reset messages as ping ?

https://tools.ietf.org/html/rfc7252

 Provoking a Reset
      message (e.g., by sending an Empty Confirmable message) is also
      useful as an inexpensive check of the liveness of an endpoint
      ("CoAP ping").

--
Julien Vermillard

On Tue, Apr 26, 2016 at 2:47 PM, core issue tracker <
[email-masked]> wrote:

> Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/394#comment:1
> >
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 26 Apr 2016 15:40:09 +0200

>       useful as an inexpensive check of the liveness of an endpoint

CoAP over TCP/TLS/WebSockets does not have Reset messages. But it is
possible to use an empty message (0.00 code) for pings, which would be
in line with CoAP over UDP/DTLS. Do we need pongs?

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 Apr 2016 15:52:26 +0200

> in line with CoAP over UDP/DTLS. Do we need pongs?

Now that would be "overloading"...

(But yes, we could specify that an empty message has no effect in a
CoAP-over-reliable connection.)

One argument for pongs was that they can provide a way to get assurance
from an application that it actually has processed notifications.
Of course, that would be additional semantics beyond the simple
ping/pong, so it would most naturally be an option in a signaling message.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Apr 2016 18:44:22 +0200

Hi Julien,

Very good question.

The thought process behind introducing a new request/response message
pattern here was that we wanted to separate functionality that concerned
the shim header protocol from the actual CoAP protocol exchange. What
may confuse a little bit is that we are trying to re-use the CoAP
protocol encoding for the shim header protocol as well.

In the write-up we will obviously have to make sure that this difference
is clearly pointed out (somehow).

Ciao
Hannes

On 04/26/2016 03:32 PM, Julien Vermillard wrote:
> On Tue, Apr 26, 2016 at 2:47 PM, core issue tracker
> <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     #394: Ping/pong
> 
> 
>     Comment (by [email-masked]
>     <mailto:[email-masked]>):
> 
>       [email-masked] <mailto:[email-masked]>         |  [email-masked]
>     <mailto:[email-masked]>
>     Ticket URL:
>     <https://trac.tools.ietf.org/wg/core/trac/ticket/394#comment:1>
>     [email-masked] <mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Apr 2016 18:45:44 +0200

I prefer to have a ping/pong exchange to improve readability without a
lot of impact on anything. We clearly need a response message to the
request in order for this stuff to work.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Apr 2016 20:39:29 +0200

In
https://mailarchive.ietf.org/arch/msg/core/W_fOB3ZrqCoUduVsovfZSHNcWMw I
wrote:

* Ping, pong: A ping message is responded to by a pong message with
  the same token.  No options are defined for Ping messages in this
  specification, but options might be defined later.  As with all
  signaling messages, the receiver of a ping or pong message MUST
  ignore elective options it does not understand.

Assumption here: echoing back a token is what we need (maybe there is a
point in echoing the payload, but maybe there also is a point in that
just being a diagnostic payload).  Simply counting pings and pongs will
also work for most applications.

So a ping might look like this (codepoints pulled out of thin air):

len tkl code token
0   4   7.11 0x47110815

The pong for that would be:

len tkl code token
0   4   7.12 0x47110815 (echoed back)

Here, the pinging application wanted to have four bytes echoed back (but
zero bytes would work as well, making this a two-plus-two-byte exchange).

Note that options could be added later (e.g., giving the whole exchange
checkpoint semantics); so the receiver of the ping should run the
message through the normal CoAP decoder and ignore elective options).

A simple keepalive message a la Julien would be:

len tkl code token
0   0   0.00 (empty)

(the only point of this "No-Op" is to refresh a NAT binding; there is no
application semantics.  So there also is no point in having options.)

Grüße, Carsten