Re: [core] #396 (coap-tcp-tls): L1 vs. L3 Encoding Approach

Hi,
The ongoing work on CoAP over Websockets  will be really useful so far as 
running CoAP in an enterprise network (with firewalls having port 
filtering) is concerned. Websocket does not add too much overhead as well. 
Running CoAP on TCP in the enterprise scenario still needs to raise 
special request to the network administrator to open ports. So, would 
really like to see the CoAP on Websocket work to mature. 

Is there any implementation available for this 
draft-savolainen-core-coap-websockets-06 please? 

The "CoAP on TCP" and "CoAP on Websocket" both fundamentally solve the 
problem of running CoAP on reliable transport. So both work should 
progress in tandem. May be it can be viewed like "CoAP over TCP" forming 
the generalization while "CoAP over Websocket" becoming a specialization 
with version determination and payload length identification off- loaded 
to Websocket mechanism. May be, the scenario of huge data transfer becomes 
a special case which gets well handled by the Websocket variant keeping 
the TCP-only variant less complicated. 

Regarding the reported results on block-wise transfer on TCP, I am 
assuming that both end points were connected over an all-TCP transport. In 
block-transfer the application layer flow-control mechanism makes every 
block transfer a closed loop exchange. That contributes to the overall 
latency as well. While running on  TCP-only transport probably we can do 
away with the application layer flow control mechanism and make the block 
transfers completely open-loop (NON + No-Response ?). (And BERT relieves 
us a bit on the fragment size constrains). The last block (M=0) should 
trigger a response from the server indicating the state of the request 
execution (assuming a PUT/ POST).
However, not sure if block-wise transfer will be required for a TCP-only 
transport between the end-points.

However, the following statement should have been modified a bit. 
>> Of course, we may not need to use Block Transfer in CoAP when we 
already use CoAP over TCP.
It may be relevant when we have all through TCP. Of course block-mode will 
be required with the TCP variant of CoAP in order to talk to the classical 
CoAP (I mean RFC 7252) end-point with constrains as nicely mentioned in 
section 4.1 of draft-ietf-core-coap-tcp-tls-01. 

Sorry if I have missed anything due to lack of attention to the chain of 
discussions on these topics.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________

From:   Carsten Bormann <cabo@tzi.org>
To:     trac+core@zinfandel.tools.ietf.org
Cc:     core@ietf.org
Date:   03/26/2016 10:09 PM
Subject:        Re: [core] #396 (coap-tcp-tls): L1 vs. L3 Encoding 
Approach
Sent by:        "core" <core-bounces@ietf.org>

>  We have not taken the performance aspect of larger file transfers 
(e.g.,
>  transfer of a 4MB firmware update) into account when we made the
>  solution decision in Yokohama. The reason why the OIC/OCF take such
>  large file transfers into account is because of their desire to use 
CoAP
>  also for non-constrained devices.

Actually, we did discuss larger transfers in Yokohama (although the word
"performant" only occurs once in the minutes, specifically where
Matthias reported on the IoTivity work).  The understanding was that an
extension to -block like draft-bormann-core-block-bert would reduce the
performance gap between a 16-bit (L1) and a 32-bit length (L3), if
needed.  The sentiment in the room was a bit against creating a dialect
of CoAP with much larger payload sizes than the ones recommended in
section 4.6 of RFC 7252, but we didn't really have much input on this to
work from.

So this particular question really reduces to:  Should CoAP be extended
to provide payload sizes well over 64 KiB over TCP, TLS?  (The
Websockets framing already provides the capability, up to 16 EiB.)

Grüße, Carsten

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you