Hi Markus et al,
I am not sure email is the best to resolve this since it is hard to understand
and sync with what folks are thinking and not just what they are saying. Or
maybe it?s just that I am very email challenged.
There are so many issues to consider to get a holistic view of this. When
looking just at Interfaces it may seem an overkill/over engineer but when many
other requirements are added it would make sense ? not sure I can reproduce all
of this and be relevant to the thread. For example, MTU came out in the
discussion but the discussion did not start with that and many did not consider
this requirement in the discussion ? we just started with ?default? interface.
Just like MTU there are other requirements. Let me see if I can even try
without creating new issues ? don?t know where to start - do I step back and
provide a bigger picture or just continue with this thread ? what seems simple
from a narrow point of view may not be as simple when viewed with the bigger
picture.
I expect this to be controversial so let me say this early and get it over with
? I don?t regard ?draft IETF spec? as gospel and, I believe, we don?t need to
adopt them; a draft is just that a draft ? on the contrary, I think we need to
influence them with our modifications and have these included in their next
draft.
To set the context with
1. I agree with your observation on small payloads and this has been an OIC
principle from day one.
2. Let me introduce another one of the principles that is relevant too:
a. OIC supports multiple transports
i. If all we are doing is
building yet another CoAP implementation then I think the simplest thing
(following ?keep it simple?) we can do for the industry is to ?disband OIC and
Iotivity?. There are already many siloes and ?CoAP oriented? siloes ? the
industry doesn?t really need the fragmentation with one more.
ii. We recognize that there are
many transports and significant balkanization in the industry today ? OIC would
really add value by providing an ecosystem that encompases all these multiple
transports (not just CoAP) and creates larger ecosystem than any one of these
siloes while still leveraging the optimizations that each of these transports
were developed for (e.g. BLE for radio and device power for example). This
means that on a device with two radios ? BLE and WiFi ? OIC can do discovery on
BLE and initial discovery using WiFi. For devices that share both BLE and WiFi
a device can turn off WiFi until it is really required for either big requests
or responses or streaming sessions. All this done opaque to the application.
This can save power.
iii. Even if BLE and WiFi devices
have no radio overlap now with a single discovery protocol at the Resource
Model layer we have made the application aware of a larger ecosystem without
any extra effort from the app. If we cannot or strongly feel we must not then
please see 2.a.i. This larger ecosystem will ?simplify the industry and
application development? but OIC must do the heavy lift ?once? so that everyone
benefits many times. So ?keep it simple? comes in many forms depending on point
of view ? protocol, system, app developer etc.
3. If we are multi-transport then binding our solution to any one transport
is counter-productive. So specification of ?media-types? using Accept is one
approach that is transport centric which is one drawback ? another is that it
only describes the representation but as we discussed we need to consider more
than just the representation. Another way to meet the same in a transport
agnostic way is to use Interfaces because ?media types? can be used in the
definition of the Interfaces ? Interfaces have other benefits too beyond this.
4. Regarding the unlikeliness of use of multiple interfaces ?
a. I am not sure you have read the OIC Spec so am not sure if you have
looked at the concept of Collections and Links. I can see where you are coming
from on single interfaces with respect to simple Resources/Resource Types but
Collections require Interfaces or it makes the query specification and
processing complex. So having one set of concepts that map consistently across
simple Resource and Collections is ?keep it simple? in my mind.
b. Going with the assumption that we can create a new URI with single
interface for every view of a single Resource. The implications of this is that
for every resource we can have multiple URIs in the /oic/res discovery response
for the same resource ? so now, in order, to remove Interfaces we have made the
discovery packets larger and so have violated point #1 which we both agree on.
Multiple Interfaces makes discovery compact while still allowing for a rich
interaction.
c. The example uses only ?baseline? and ?sensor? ? but we also have
?actuator?. How does one distinguish between the ?read only? semantics of
sensor with the ?read/write? semantics of actuator using Accept? Each of these
interfaces encapsulate behavior in addition to representation.
5. With multiple Interfaces it is a simple step to also allow deployments to
fine tune the environment to the solution or application being developed by
allowing Resource to advertise a ?default?. Default does not always means the
smallest packet on the network ? it is the Interface that is most likely used
in that solution scenario and so keeping that interaction and the request
structure simple would drive the biggest benefit.
Well ? I think we have reached the limits of email because there is more that
is ?unsaid? than ?said?. And, my perception, is that it is the ?unsaid? POV or
philosophies that are really driving the discussion and without a way to put
that out efficiently we will be spinning and talking past each other.
Anyway ? The spec has been released with multiple Interfaces so I think it is
best we continue forward and not debate this further. As far as default
Interface ? in the spirit of compromise and moving on ? one thing I could
suggest but needs to be ratified by CFTG is that the spec leaves ?default
Interface identification? as is and uses the current mechanism of ?first on the
list? and then Iotivity could then ignore it by explicitly using ?query
parameter? if= in *all* their requests (setting any Interface first for
Iotivity Resource would not matter since that is ignored). I am not sure where
Iovitity is on implementing Collections ? I expect we would need to reopen this
discussion when we get to that bridge.
Thanks!
Ravi
From: Markus Jung [mailto:markus.j...@samsung.com]
Sent: Thursday, February 4, 2016 6:53 PM
To: Mitch Kettrick <cpm at openinterconnect.org>; Subramaniam, Ravi
<ravi.subramaniam at intel.com>; Maloor, Kishen <kishen.maloor at intel.com>;
Macieira, Thiago <thiago.macieira at intel.com>; oswg at openinterconnect.org
Cc: iotivity-dev at lists.iotivity.org
Subject: Re: RE: [oswg] Re: [dev] Default interface signaling
Hello,
a few comments on the discussion.
A short conclusion:
- OIC/IoTivity should by default always favor small payloads.
- Default interfaces fixed of a resource type in the spec should work well
- Having multiple interfaces is very unlikely and will be very unlikely. We
have the issue only because oic.if.baseline is used to add meta-information to
a resource. That's most likely the only case where we will run into this
problem and can be easy to solve. For example, by default no metadata is
provided only if the client requests.
1. In IoT every byte counts
I agree to Mitch that message size is very relevant and has significant
implications on power usage and performance in constrained networks. Since we
are using CoAP we should take the initial design decisions into considerations,
which were mainly targeting 802.15.4 based networks (6LoWPAN, Thread, Zigbee).
15.4 frames give you 127 bytes, out of which you can use only 50-60 bytes to
avoid fragmentation. Fragmentation is undesirable for a number of reasons [1].
So every byte on the wire counts. Take on the example below. If you send a CoAP
message with a simple URI-path and a simple text-based payload 35 bytes are
easily used. So a careful design of URI paths, query arguments and payload is
required.
However, on a GET request with an empty payload only around 10 bytes would be
consumed for specifying the interface to be oic.if.s.
[cid:image001.gif at 01D15F83.FDCC6380]
2. Keep it simple
The discussion takes a bit off and seems to over-engineer a simple problem.
Taking the intial source of the interface concept the typical use case would be
that a
resource only provides only a single interface
(http://www.ietf.org/id/draft-ietf-core-interfaces-04.txt). In OIC this concept
has been taken and modified, which causes a bit headache now.
The most relevant distinction will be if metadata should be included
(oic.if.baseline) or not (oic.if.s).
In the RFC draft the accept header option is used to make this distinction,
below a simple example for a humidity sensor. This approach is better since the
accept option can be compressed in the CoAP header. It uses 1 byte instead of
15 bytes (oic.if.baseline as text).
Req: GET /s/humidity (Accept: text/plain)
Res: 2.05 Content (text/plain)
80
Req: GET /s/humidity (Accept: application/senml+json)
Res: 2.05 Content (application/senml+json)
{"e":[
{ "n": "humidity", "v": 80, "u": "%RH" }],
}
[1] The Wireless Embedded Internet, Zach Shelby, 2.7.2 Avoiding the
fragmentation performance penalty
Best regards
Markus
------- Original Message -------
Sender : Mitch Kettrick<cpm at openinterconnect.org<mailto:cpm at
openinterconnect.org>>
Date : Feb 05, 2016 04:26 (GMT+09:00)
Title : RE: [oswg] Re: [dev] Default interface signaling
Hi,
Just to add a few points/clarifications to what Ravi has said:
1. From a test and certification standpoint, we will be verifying that
read-only Properties cannot be written/updated regardless of the Interface
used. In other words, even though oic.if.baseline supports writing, you should
not be able to update a read-only Property when using it. This will be checked.
2. Think about a sensor that is asked to send it?s temperature every
second. With oic.if.baseline, the message would looks something like:
{
"rt": "oic.r.temperature",
"if": "oic.if.a oic.if.baseline",
"temperature": "20",
"units": "C",
"range": "0,100"
}
That same message using oic.if.s may look like:
{
"temperature": "20",
}
