Kai, Julien, all,
thanks so much for the clarifications. Since the NAT is not under “control” in a CGN scenario, it would be interesting so see how long the CGNs router can stay “open” long enough in such scenarios. My additional research concluded that CGNs seem to be not widely deployed in the wild (yet) by telcos, so this is probably more of a theoretical discussion right now. Has anyone gathered more information about already deployed CGNs in the wild for mobile networks, especially which telcos already use CGNs?
I’m interested in doing some experiments with the CoAP Observe feature over mobile networks in the future, I’m curious how this turns out. If anyone has experience with that yet and the non-obvious pitfalls, I would of course be very interested to learn how to avoid these pitfalls (beside doing excessive heartbeats). My feeling right now is, that CoAP over TCP would be the easiest and most reliable way for cloud to device communication with CoAP. If someone has already done a comparison of CoAP over TCP and MQTT in terms of protocol overhead, this information would also be very interesting.
Thanks for the great and valuable discussion, Dominik
-- Dominik Obermaier
dc-square GmbH - Software Solutions
Innere Münchener Straße 30
84036 Landshut
Tel. +49 871 - 97506300
Fax. +49 871 - 97506329
Web. www.dc-square.de
Geschäftsführer Christian Götz, Dominik Obermaier
Registergericht Landshut, HRB 8906
USt.ID: DE283445184
On 30 Nov 2015 at 18:30:12, Roger Light (roger@xxxxxxxxxx) wrote: Hi Julien,
I should have been clearer as well - my point was just to give another
useful datapoint. Comparing DTLS+PSK to TLS+x509 doesn't tell you a
great deal because both parts are different. With TLS+PSK as well it
is clearer which parts add the overhead.
Cheers,
Roger
On Mon, Nov 30, 2015 at 3:24 PM, Julien Vermillard
<jvermillard@xxxxxxxxx> wrote:
> Sorry, I probably miss phrased "usual TLS/TCP".
>
> Yes TLS PSK is also quite compact, but mosquitto is the only broker I know
> which support it.
> (ex: hivemq or aws iot doesn't support it). So in my view it's not "usual".
> For example it's not working for Paho Java because TLS PSK is not in the
> Java JDK :(
>
> For CoAP it's somewhat the default ciphersuite because it's in specified as
> "mandatory" in the RFC.
> It's often the X.509 authentication which are not supported on constrained
> CoAP nodes and networks.
>
> --
> Julien Vermillard
>
> On Mon, Nov 30, 2015 at 4:05 PM, Roger Light <roger@xxxxxxxxxx> wrote:
>>
>> On Mon, Nov 30, 2015 at 8:30 AM, Julien Vermillard
>> <jvermillard@xxxxxxxxx> wrote:
>>
>> > In practice the device communicates regularly with the server (for
>> > example:
>> > every 15 min to once a week) or when some data are ready to send.
>> > For that CoAP beat MQTT in byte consumption because DTLS PSK both way
>> > handshake is ~800 bytes where a usual TLS/TCP handshake is 4k~6k and
>> > piggybacked ack save also few more bytes over TCP ACKs.
>>
>> For completeness, I just used wireshark to grab packets when
>> connecting with a mosquitto_sub that had been nobbled not to send any
>> real data to a mosquitto instance listening with TLS-PSK over TCP.
>> The total on the wire byte count was 1419.
>>
>> Cheers,
>>
>> Roger
>> _______________________________________________
>> iot-wg mailing list
>> iot-wg@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/iot-wg
>
>
>
> _______________________________________________
> iot-wg mailing list
> iot-wg@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/iot-wg
_______________________________________________
iot-wg mailing list
iot-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-wg
|
