Subject: [core] Response suppression

From: "Angelo P. Castellani" <[email-masked]>
Date: Sun, 24 Mar 2013 15:44:08 +0100

Dear WG,

one-way traffic could be a requirement in future application scenarios
that need to keep the network unloaded of unrelevant traffic. (I have
various examples in mind, if you feel that it's worth I can contribute
some ideas)

If a response suppression mechanism is built into the protocol, even
this situation could be addressed using CoAP.

I've given it a quick try, you can read my proposal in the following
part of the message. However if any seasoned protocol-designer has
better proposals for supporting this feature, please propose it here.

I propose to restrict TKL field to a 3-bit size, as originally
proposed by Klaus
(http://www.ietf.org/mail-archive/web/core/current/msg03832.html).
Note that right now TKL values 9-15 are reserved, so this means that
actual encoding does not change.

If we get back this reserved field we can use it for response
suppression as described in the attached text file.

Best,
Angelo

p.s.: probably for applicating this in the multicast case we need a
little more work

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 24 Mar 2013 16:08:59 +0100

There are two proposals here:
1 -- introducing a way to indicate that a response is not desired;
2 -- changing the four-byte header to carry that indication.

There are a quite a few ways to provide the indication (1) that have fewer side-effects on what we have now than (2).
Let's focus first on what the scenarios for application of response-less methods would be, and then discuss how to encode them.
(Just as an existence proof, obviously, the same information could be carried in an Option with a single-byte encoding, or as separate method numbers.)

(As a protocol design meta-comment: There is a strange attraction from unused or reserved bits/bit combinations in a protocol, constantly moving people to invent ways to fill them.  That is not good for further evolution of the protocol, which often requires reserved bits/bit combinations to be available.  There is always more need to evolve a protocol than is apparent from the information available at a specific point in time.)

So what are the application scenarios for response-less methods?

Grüße, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Sun, 24 Mar 2013 16:24:07 +0100

Generally speaking, IMHO, there are two scenarios when response is not
desidered:

1 -- in any case the response is not desidered, e.g., for timing
reasons, or because the client operation does not depend upon the
response

2 -- some responses are not desidered, e.g., see multicast requests
and client-errors (404) from some, possibly many, servers

In my point of view, case (1) is typically the case of high-priority
commands. Something like "Hey, Do this! If you fail, there is no other
possibility of doing this". Case (1) fits very well with having this
in the header because this approach does not deserve enlarging the
message, and the server (or even the network) can possibly process (or
even relay) this message with higher priority than the others.

Case (2) probably works better with an option that specifies criteria
to understand which are the undesidered responses.

I hope this clarifies my point, and motivates the reason why I put it
in that very "tempting" part of the header :-)

Best,
Angelo

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 25 Mar 2013 09:05:25 +0000

For more relevant input to this discussion, see: http://tools.ietf.org/html/draft-ietf-core-groupcomm-05#section-3.6
It aims to show why response suppression is needed for multicast responses; and proposes a solution for configuring response suppression on CoAP servers that is not too complex but still suitable for the intended purposes/use cases.

In my view a CoAP option for response suppression sounds useful and relevant in this context; however we then have to clearly list both advantages and disadvantages of this approach against the current approach in the GroupComm draft based purely on server/per-resource configuration.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Angelo P. Castellani
Sent: Sunday, March 24, 2013 16:24
To: Carsten Bormann
Cc: core
Subject: Re: [core] Response suppression

1 -- in any case the response is not desidered, e.g., for timing reasons, or because the client operation does not depend upon the response

2 -- some responses are not desidered, e.g., see multicast requests and client-errors (404) from some, possibly many, servers

In my point of view, case (1) is typically the case of high-priority commands. Something like "Hey, Do this! If you fail, there is no other possibility of doing this". Case (1) fits very well with having this in the header because this approach does not deserve enlarging the message, and the server (or even the network) can possibly process (or even relay) this message with higher priority than the others.

Case (2) probably works better with an option that specifies criteria to understand which are the undesidered responses.

I hope this clarifies my point, and motivates the reason why I put it in that very "tempting" part of the header :-)

Best,
Angelo

2013/3/24 Carsten Bormann <[email-masked]>:
> (Just as an existence proof, obviously, the same information could be
> carried in an Option with a single-byte encoding, or as separate
> method numbers.)
>
> (As a protocol design meta-comment: There is a strange attraction from
> unused or reserved bits/bit combinations in a protocol, constantly
> moving people to invent ways to fill them.  That is not good for
> further evolution of the protocol, which often requires reserved
> bits/bit combinations to be available.  There is always more need to
> evolve a protocol than is apparent from the information available at a
> specific point in time.)
>
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.