Subject: [Taps] Hello from CoRE

From: Christian Amsüss <[email-masked]>
Date: Mon, 26 Mar 2018 15:28:01 +0200

Hello taps-interface authors,

I was having a look at the work of the TAPS Group on suggestion of
Theresa; my context is as an implementor the CoAP protocol, which is a
primarily UDP based protocol for RESTful interaction in constrained
("IoT") environments (short: CoRE).

That protocol is a bit tricky to implement in full on POSIX sockets
because it requires that responses be sent from the destination address
of the request, and because role reversal (a server that has received
requests starts sending requests to the original client) means that even
a server needs to receive ICMP errors on messages it sends. While this
can be done on POSIX using various socket options and sendmsg/recvmsg,
it is not trivial to implement and sometimes badly supported by
platforms and language bindings.

I've had a look at the abstract API outlined in trammell-taps-interface,
and it seems to be suitable for implementing CoAP in a much more
straightforward way, but I don't know yet whether it can do the
following:

* Can the API be instructed that a UDP package shall go out on the same
  IP and port as a given received package? (CoAP requirement)

* Can a listening (pre)connection be used to initiate a connection
  actively from the listening port? (This is convenient to have because
  it allows hosts to advertise their server role in a client capacity
  without needing to transmit their own server address explicitly).

* Can the API be used for sending and receiving multicasts (or will
  provide that in a later form)?

* On the topic of DTLS protected connections: Can the API give me a
  handle to (or representation of) an outgoing packet in its encrypted
  form, so that I can issue a retransmit at a later time using the same
  DTLS sequence number?

  (There are mechanisms being specified with which CoAP can deal with
  malicious reordering, but those keep track of lost packages. If the
  packages get retransmitted as-was and get ack'ed, that mechanism can
  save a few bytes).

* For CoAP, it is recommended to introspect an returning ICMP error to
  see whether it is genuine (the headers match a sent package) and
  relevant for various reasons (RFC7252 Section 4.2).

  Will the API provide that detail to the protocol implementor, or can
  the protocl implementor configure how to treat which errors?

And last but not least: Is there an implementation of this around I
could experiment with?

Best regards,
Christian

PS. Please keep me in To/Cc when replying, as I am not subscribed to the
TAPS mailing list.

-- 
We are dreamers, shapers, singers, and makers.
  -- Elric

---

From: Chris Wood <[email-masked]>
Date: Mon, 26 Mar 2018 06:33:25 -0700

Hi Christian,

Please see inline below.

Best,
Chris

> On Mar 26, 2018, at 6:28 AM, Christian Amsüss <[email-masked]> wrote:
> 

No. Such details are hidden beneath the API. Retransmission, for example, would be something you specify on a per-message basis.

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 26 Mar 2018 16:10:20 +0200

Hello Chris,

On Mon, Mar 26, 2018 at 06:33:25AM -0700, Chris Wood wrote:
> > * On the topic of DTLS protected connections: [...] so that I can
> > issue a retransmit at a later time using the same DTLS sequence
> > number?
> 
> No. Such details are hidden beneath the API. Retransmission, for
> example, would be something you specify on a per-message basis.

Would that mean that I can tell it to send this particular message with,
say, "retransmissit roughly after 2s, exponentialy fallin off with
factor 2 for up to 4 transmissions", and can call off retransmission of
that message when I've decoded a CoAP ACK?

For that would work just as well.

I'd only need to be informed whether the implementation retransmits with
the same or a DTLS new sequence number, and whether such a retransmit
actually happened. (The feedback to the application about the
retransmits is not only relevant to the encrypted case, but also to tune
the retransmission for applications as [1]).

Thanks
Christian

[1]: https://tools.ietf.org/html/draft-ietf-core-cocoa-03

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Chris Wood <[email-masked]>
Date: Mon, 26 Mar 2018 08:44:10 -0700

> On Mar 26, 2018, at 7:10 AM, Christian Amsüss <[email-masked]> wrote:
> 
> Hello Chris,
> 

I don’t know if the API as specified permits such fine-grained control, though it certainly seems within reason. 

> the retransmission for applications as [1]).

Makes sense. Thanks for bringing this use case to the group!

Best,
Chris

---

From: Michael Welzl <[email-masked]>
Date: Mon, 26 Mar 2018 22:19:53 +0200

Dear Christian,

Thanks a lot for your interest!
I see you got a few answers already; I’ll complement with a few more, in line:

> On Mar 26, 2018, at 3:28 PM, Christian Amsüss <[email-masked]> wrote:
> 

I think “will provide that in a later form” is the right answer here.

>  the protocl implementor configure how to treat which errors?

I think our goal is to describe something reasonable:
- not too large
- yet not entirely "lame"
- and implementable

I would say that a TAPS implementation should probably be free to provide details such as the one you’re asking for here, but on the other hand, I think we need to set some bounds to the list that will end up in our doc as “a TAPS implementation MUST …” - it’s easy for this list to grow endlessly. *Right now*, your requested ICMP functionality is not in our list. I also suspect that it falls in the category of “can be done under the hood”. Whatever can reasonably be done under the hood should not be exposed in our API.

> And last but not least: Is there an implementation of this around I

Yes, we have NEAT:
https://github.com/NEAT-project/neat <https://github.com/NEAT-project/neat>
 - please do play with it !

Cheers,
Michael

---

From: Theresa Enghardt <[email-masked]>
Date: Wed, 28 Mar 2018 10:55:20 +0200

Hi Christian,

thanks for your interest and for the really good questions.

On 26.03.2018 15:28, Christian Amsüss wrote:
> […]

Yes. The application would have to create a connection with the desired
properties, e.g. similar to UDP, specify a certain IP address and port
as local endpoint, receive messages on the connection (=UDP packets),
and then send on the same connection, thus using the same IP address.

>   without needing to transmit their own server address explicitly).

I think the API allows it. You call Listen() on the Preconnection and
you get ConnectionReceived events, but you can still call Initiate() on
the same Preconnection. But I'm not sure what happens then... something
to think about :)

Best,
Theresa

-- 
Theresa Enghardt
Wissenschaftliche Mitarbeiterin / Research Assistant
Phone: +49 30 314 78628
Office: MAR 4.032

FG / Group "Internet Network Architectures" (INET)
Technische Universität Berlin
Sekr. MAR 4-4, Marchstraße 23, 10587 Berlin