Submit to this Journal Review for this Journal Propose a Special Issue

Article Menu

Share Help Cite Discuss in SciProfiles

Open AccessFeature PaperArticle

Peer-Review Record

CoAP-Based Streaming Control for IoT Applications

Electronics 2020, 9(8), 1320; https://doi.org/10.3390/electronics9081320

by Joong-Hwa Jung¹

, Moneeb Gohar² and Seok-Joo Koh^1,*

Reviewer 1: Anonymous

Reviewer 2: Anonymous

Reviewer 3: Anonymous

Reviewer 4: Anonymous

Electronics 2020, 9(8), 1320; https://doi.org/10.3390/electronics9081320

Submission received: 23 June 2020 / Revised: 31 July 2020 / Accepted: 13 August 2020 / Published: 16 August 2020

(This article belongs to the Special Issue IoT Services, Applications, Platform, and Protocols)

Round 1

Reviewer 1 Report

The authors propose a Constrained Application Protocol (CoAP) based on Streaming Control, featuring advantages in terms of delay, number of retransmitted packets over CoAP over UDPs, and TCPs.

Despite the proposed protocol looks promising, some improvements shall be carried out before publication:

-----------------Major point------------------------------

The authors mentioned that some other works in literature tried to improve CoAP based on UDP and TCP. Because of that, they should clarify is the implementations of CoAP over UDP and TCP used for the analysis and comparison exploit standard versions of protocols or if they include some improvements proposed by other works. In the first case, a comparison with the literature should be performed to state the overall merit of the work.

-------------------Minor points---------------------------

Even if the article is not proposing a CoAP as a protocol for IoT but is promoting a possible improvement, I think it would be interesting to provide the readers some background about CoAP and its possible applications. In particular, it would be interesting highlighting the possible benefits due to the use of CoAP compared to the bare use of UDP and TCP.
Fault-detection condition line 159: Is it not dataMsg.SN - receiver.AN as stated at lines 166 - 167?
Line 282: "TTD means the total time duration elapsed for streaming transport, which represents overall throughput performance". It would be better to say that is correlated since a delay is not "a throughput".

Author Response

The authors propose a Constrained Application Protocol (CoAP) based on Streaming Control, featuring advantages in terms of delay, number of retransmitted packets over CoAP over UDPs, and TCPs. Despite the proposed protocol looks promising, some improvements shall be carried out before publication:

The authors mentioned that some other works in literature tried to improve CoAP based on UDP and TCP. Because of that, they should clarify is the implementations of CoAP over UDP and TCP used for the analysis and comparison exploit standard versions of protocols or if they include some improvements proposed by other works. In the first case, a comparison with the literature should be performed to state the overall merit of the work.

Even if the article is not proposing a CoAP as a protocol for IoT but is promoting a possible improvement, I think it would be interesting to provide the readers some background about CoAP and its possible applications. In particular, it would be interesting highlighting the possible benefits due to the use of CoAP compared to the bare use of UDP and TCP.

Thanks for the valuable comments. Based on the comments, more detailed description of the existing CoAP over UDP and CoAP over TCP schemes, with packet analysis and the concerned figures, has been added to Section 2 (related works) in the revised paper. The description of the streaming method based on the CoAP-Observe option has also been added, together with detailed packet analysis for the existing schemes by using the Wireshark.

In CoAP over UDP, when packet loss occurs, retransmission is performed only when a timeout event occurs, and thus it may not give good performance in services that need to process messages sequentially. The CoAP over TCP provides fast retransmission function of TCP, but the loss of ACK can cause problems, such as retransmission and HoL blocking. The corresponding discussion and description are given in Section 2. In addition, we also discussed the issue of the IP address change in the streaming transport so as to see the effect of TCP 3-way handshaking on the real-time service.

With the revision of Section 2, Section 3 was also revised for clarification, based on the comments, in which the characteristics of the proposed CoAP-SC scheme are described more in detail.

Thanks again for the helpful comments.

Fault-detection condition line 159: Is it not dataMsg.SN - receiver.AN as stated at lines 166 - 167?

Line 282: "TTD means the total time duration elapsed for streaming transport, which represents overall throughput performance". It would be better to say that is correlated since a delay is not "a throughput".

Based on the comment, the concerned texts are corrected in the revised paper. Thanks for the helpful comments and suggestions.

Author Response File: Author Response.pdf

Reviewer 2 Report

Generally, there seems to me that there are some good ideas in this work and proposing a new
protocol is always interesting. However, the whole presentation needs to change for the paper
to be in an acceptable form. Please, see the details below.

1) From the abstract, the authros state that " However, these existing schemes do not
provide the error handling and flow controls suitably for IoT-based streaming applications. This tends to induce throughput degradation
in wireless lossy networks". Please give reasoning, especially for "suitably. It is knonw that the
TCP offers reliabile flow control and error handling, so explain the problem (perhaps in the introduction
section). The explanation given in Section 2.2 is not detailed. The authors just clain that the handshaka
and the congestion control increase the overhead. More specifically the authors should add
more explanation regarding:

- How big are these overheads
- How and why they affect streaming applications
- According to the recent bibliography, in streaming applications
the nodes distance plays the most importan role in the internode communication. Is the congestion
control and the handshake procedure of TCP so important? Please give reasoning
- Also, from fig. 4, one needs to see clearly the size of these messages, to understand the "burden".

2) Section 3, second paragraph

In the proposed scheme, we assume that a sender (client) transmits the streaming data to a
receiver (server) periodically and sequentially for IoT streaming transport. We propose the streaming
control mechanisms for throughput enhancement. The proposed control mechanism performs the
error handling and flow control functions. To do this, the sequence number (SN) is assigned to each
data message by sender, and the ACK number (AN) is given by receiver to confirm successful
reception of data message. Please, explain the difference to the simple TCP.

3) "The proposed scheme begins with an initialization operation so as to arrange the resources for
streaming transport"

Please explain what operations are performed here. Who arranges the resources and what is the criteria?
From what i understand, the resources include bandwidth, buffer memory, links etc. If not, please explain t
it is not clear.

4) Section 3.2: This point needs clarification. The authors include an example, but they should also
explain what the simple TCP would do and clarify the differences and the advantages of the Error Handling
method they propose.

5) The same as observation (4) holds for the proposed flow control mechanism

6) In Fig. 9, shouldn't the CoAp over UDP have less delays compared to CoAP over TCP? Apparentely,
it is less reliable, but it should be faster as it uses no congestion controls or error handling.
If this is not the case, please explain. Also, explanation is needed regarding the fact that
the proposed scheme outperforms the other protocols.

7 ) In Fig.10 CoAp over UDP has to retransmit more messages. This is normal, but contradictory compared
to Fig.9 , as explained. Please provide FULL explanation because the CoAp over UDP is less reliable bur
should have lower average delays.

8) Generally, all the figure should be explained in details, stressing the advantages of the
proposed protocol. The authors restrict themselves on mentioning what is compared. Unless full
explanations are given, the interested author can't understand the advantages of the proposed protocol

Author Response

Generally, there seems to me that there are some good ideas in this work and proposing a new protocol is always interesting. However, the whole presentation needs to change for the paper to be in an acceptable form. Please, see the details below.

From the abstract, the authors state that " However, these existing schemes do not provide the error handling and flow controls suitably for IoT-based streaming applications. This tends to induce throughput degradation in wireless lossy networks". Please give reasoning, especially for "suitably. It is knonw that the TCP offers reliable flow control and error handling, so explain the problem (perhaps in the introduction section). The explanation given in Section 2.2 is not detailed. The authors just claim that the handshake and the congestion control increase the overhead. More specifically the authors should add more explanation regarding:

- How big are these overheads

- How and why they affect streaming applications

- According to the recent bibliography, in streaming applications the nodes distance plays the most important role in the inter node communication. Is the congestion control and the handshake procedure of TCP so important? Please give reasoning- Also, from fig. 4, one needs to see clearly the size of these messages, to understand the "burden".

First of all, we would like to give special thanks for the valuable comments and suggestions.

As per the comments, we revised Section 2 (related works) of the revised paper, with the detailed packet analysis (using Wireshark) for the existing schemes. The revision includes a description of why the existing protocol is not suitable for streaming service. In particular, we discussed the analysis of the overhead on TCP 3-way handshaking, and the behaviors of CoAP over TCP and CoAP over UDP, in Section 2 of the revised paper. This analysis includes some packet capturing.

Section 3, second paragraph:

“In the proposed scheme, we assume that a sender (client) transmits the streaming data to are receiver (server) periodically and sequentially for IoT streaming transport. We propose the streaming control mechanisms for throughput enhancement. The proposed control mechanism performs the error handling and flow control functions. To do this, the sequence number (SN) is assigned to each data message by sender, and the ACK number (AN) is given by receiver to confirm successful reception of data message.”

Please, explain the difference to the simple TCP.

Thanks for the useful comment. To clarify the differences from TCP, we have added the corresponding description in Section 2 of the revised paper, which includes the role of Sequence Number and Acknowledgement Number in flow control and error control of the existing CoAP over TCP scheme. We also discussed the features of TCP that are not suitable for real-time IoT streaming services, (e. g., retransmission caused by loss of ACK, and the HoL blocking problem). The corresponding description is given with the packet analysis example by using Wireshark, in the revised paper.

With the revision of Section 2, Section 3 was also revised. CoAP-SC supports cumulative ACK, like TCP, but it does not transmit ACK messages in response to specific data messages. Thus, the loss of ACK messages does not lead to frequent retransmissions of data messages in the proposed scheme. The corresponding texts and figures are given into Sections 3 of the revised paper.

"The proposed scheme begins with an initialization operation so as to arrange the resources for streaming transport"

Please explain what operations are performed here. Who arranges the resources and what is the criteria? From what I understand, the resources include bandwidth, buffer memory, links etc. If not, please explain it is not clear.

In the proposed CoAP-SC scheme, the ‘buffer size’ is a very important factor for flow control. Thus, the initialization phase is purposed to inform the receiver of the “sender's available buffer size”. The other information and operations employed in the initialization phase are the same with those of the existing CoAP scheme. The corresponding texts are given in Section 3.1.

Section 3.2: This point needs clarification. The authors include an example, but **<u>they should also explain what the simple TCP would do and clarify the differences</u>** and the advantages of the Error Handling method they propose.

Thanks for the comments. Based on the comments, the paper was revised. Differently from the TCP, the proposed CoAP-SC does not retransmit the data packet in case of the ACK loss. Also, the fast retransmission mechanism is also performed together with the flow control based on the sending buffer, in the proposed scheme.

The corresponding description is given in Section 2, 3 and 4 of the revised paper, together with the detailed packet analysis. Thanks for the valuable comments.

The same as observation (4) holds for the proposed flow control mechanism.

CoAP-SC is characterized in that an ACK message is transmitted according to the sender's buffer status, rather than an ACK message being issued for the transmitted message. Through this, the number of ACK messages can be reduced, and the number of retransmissions due to the loss of ACK messages can be reduced.

We added the corresponding texts into Section 3 of the revised paper, and we added the results of the analysis through Wireshark to verify this.

In Fig. 9, shouldn't the CoAP over UDP have less delays compared to CoAP over TCP? Apparentely, it is less reliable, but it should be faster as it uses no congestion controls or error handling. If this is not the case, please explain. Also, explanation is needed regarding the fact that the proposed scheme outperforms the other protocols.

We agree with your opinion. In general, UDP provides fewer functions than TCP, and messages in UDP are processed asynchronously and are transmitted faster than TCP packets because of the small datagram size.

However, the situation that we considered is a service that requires error recovery, and CoAP over UDP showed a high delay in a network with a high error rate because retransmission occurs only through timeout. On the other hand, TCP provides fast retransmission, so if packets are lost, errors can be recovered with less delay than CoAP over UDP.

Since CoAP-SC is based on UDP, it was confirmed in the experiment that it shows the best performance by providing fast retransmission through SN and AN while taking advantage of UDP.

The corresponding description and explanations were added to Section 4 (experimentations), and the validity of each scheme was analyzed through Wireshark in Sections 2 and 3 in the revised paper.

In Fig.10 CoAP over UDP has to retransmit more messages. This is normal, but contradictory compared to Fig.9 , as explained. Please provide FULL explanation because the CoAP over UDP is less reliable but should have lower average delays.

The figure shows the average delay for each message obtained in 10 trials. In the case of CoAP over UDP, if a message is lost, retransmission occurs only after the timeout. In this way, error recovery, which is dependent on the timeout of CoAP over UDP, has increased the delay.

We have added the corresponding texts into the Section 4 of the revised paper.

Generally, all the figure should be explained in details, stressing the advantages of the proposed protocol. The authors restrict themselves on mentioning what is compared. Unless full explanations are given, the interested author can't understand the advantages of the proposed protocol.

We conducted a lot of experiments to determine the total of three numerical value (Number of Retransmission Packets, Total Blocking Time, and Total Transmission Delay). In the case of the Number of Retransmission, the proposed CoAP-SC is an important factor that can show good performance in experiments to examine the following two figures. In the case of CoAP-SC, retransmission due to loss of the ACK message does not occur, so the assumption is less NRP.

Total Blocking Time is an experiment conducted to confirm that CoAP-SC provides efficient flow control and shows good performance even in small memory. From the results of this experiment, it was confirmed that CoAP-SC showed the best performance, which is a result obtained because CoAP-SC provides cumulative ACK like TCP and has less NRP than TCP.

Total Transmission Delay is an indicator of CoAP-SC's error handling performance. CoAP over UDP has a long delay because only retransmission occurs due to timeout. CoAP-SC is UDP-based, but the receiver can quickly recover errors through retransmission requests through SN and AN. This method may be slower than the error recovery rate of TCP, but CoAP-SC showed the best performance because the number of retransmissions was significantly less than that of TCP. The corresponding texts and description are given in Section 4 of the revised paper.

Thanks for many valuable comments. We believe the paper was enhanced thanks to the valuable comments.

Author Response File: Author Response.pdf

Reviewer 3 Report

This paper needs a lot of work to develop it to a journal level article. In terms of contributions, I did not find any and if there is, it is a basic incremental one. For example, the authors indicate the addition of the sequence number (SN) to outgoing data message by sender and the ACK by receiver to confirm successful receipt of the message. TCP already does and what is new about this. The introduction lacks the proper academic paper components such as necessary background on the main topic and the motivation to the work reported in the paper. There is a practical reason for using CoAP and it is important that the authors do argue why this protocol is not useful for IoT applications. More than two-third of the related work section describes the header component of the packet. Apart from saying ‘Some works have been conducted to overcome the shortcomings of the basic CoAP model, which include the CoAP-Observe schemes [10-12]’, there is no related work in the article. Some editing and proofreading you should do include, removing repetitive statements such as on line 119, ‘Too evaluate overall performance’ should be ‘To evaluate overall performance’. You should provide details of the testing environment. In the performance section, you should add some explanation for the reason of the results. For example, Figure 9. Average Delay of Messages, you say ‘In this figure, we can see that the proposed CoAP-AC scheme provides lower delays than the existing two schemes.’ It is important you explain why this is so. How did you induce ‘ack’ packet loss to measure the retransmission number should be clearly discussed.

Author Response

Thanks for the valuable comments. Based on the comments, the paper was revised. As you pointed out, in order to clarify the characteristics of the proposed scheme in this paper, we have discussed the problems of the existing scheme with thorough analysis by using packet captures in Section 2 of the revised paper.

The proposed CoAP-SC is an extension of CoAP to overcome the disadvantages of existing CoAP over UDP and CoAP over TCP. CoAP-SC proposes a CoAP-SC option to provide fast retransmission for efficient error handling and flow control not provided by CoAP over UDP. To emphasize this, the disadvantages of CoAP over UDP and CoAP over TCP were discussed in Section 2 and Section 3 of the revised paper in details along with the packet analysis using Wireshark.

Thanks for the comments.

There is a practical reason for using CoAP and it is important that the authors do argue why this protocol is not useful for IoT applications. More than two-third of the related work section describes the header component of the packet.

Thanks for the useful comments. CoAP is a representative protocol for messaging in IoT environments. But CoAP is not suitable protocol for streaming services. In the case of CoAP over UDP, retransmission occurs after a timeout when a message is lost, and error recovery dependent on the timeout of CoAP over UDP increases the delay. In addition, CoAP over TCP provides a fast retransmission function of TCP, but it has been verified through Wireshark that the loss of ACK can cause problems such as retransmission and HOL blocking. We tried to change the IP in the streaming situation to see the effect of 3-way handshaking on the real-time service. In this case, it was confirmed that the reliability of the messages transmitted at this moment is not guaranteed, as well as the delay for reconnection.

The corresponding texts are given in the revised paper.

Apart from saying ‘Some works have been conducted to overcome the shortcomings of the basic CoAP model, which include the CoAP-Observe schemes [10-12]’, there is no related work in the article.

The basic CoAP does not provide flow control. To overcome these shortcomings, we can use options as CoAP observe. As per the suggestion, we added the flow control using CoAP Observe in Section 2.

The corresponding description is given in Section 2 and 3 of the revised paper.

Some editing and proofreading you should do include, removing repetitive statements such as on line 119, ‘Too evaluate overall performance’ should be “To evaluate overall performance.”

Thanks for the useful comments. Based on the comment, the editorial enhancement was made throughout the paper.

You should provide details of the testing environment. In the performance section, you should add some explanation for the reason of the results. For example, Figure 9. Average Delay of Messages, you say ‘In this figure, we can see that the proposed CoAP-AC scheme provides lower delays than the existing two schemes.’ It is important you explain why this is so. How did you induce ‘ack’ packet loss to measure the retransmission number should be clearly discussed.

Thanks for the valuable comments. Based on the comments, the testbed configuration is given more in details in the revised paper. Each experimental result is discussed more in details in Section 4 of the revised paper. Two new figures for experimentation are also added in the revised paper.

Author Response File: Author Response.pdf

Reviewer 4 Report

The authors propose a CoAP-based streaming control (CoAP-SC) scheme, which is an extension of CoAP over UDP with the error handling and flow controls for reliability and throughput enhancement. It is more practical than CoAP over TCP because the TCP 3-way handshake messages is a heavy burden for IoT devices.

As shown in figure 6, the resources can be exhausted when asking for a retransmission of a specific packet. The authors should point out some potential solutions to that problem such as network coding or erasure coding where you send linear combinations of the data [1,2,3]. This comes with a cost of increased delay, but it can be regulated with the generation size.

Adding the CoAP-SC option header format increases the packet size and we want to send as less bytes as possible in IoT networks. The authors should comment on that drawback and state some thoughts about header reduction by using techniques such as [4].

The performance analysis section looks good although the error rate can be bigger than 0.3, then the performance of the proposed algorithm is expected to become worse.

[1] S. Feizi et al. Tunable sparse network coding for multicast networks. In Network Coding (NetCod), 2014 International Symposium on, pages 1–6, June 2014.
[2] D. Gligoroski and K. Kralevska, "Families of Optimal Binary Non-MDS Erasure Codes," IEEE Proceedings on International Symposium on Information Theory (ISIT), ISBN 978-1-4799-5186-4, pp. 3150-3154, 2014
[3] G. Biczók et al., "Combining Forward Error Correction and Network Coding in Bufferless Networks: a Case Study for Optical Packet Switching," IEEE 17th International Conference on High Performance Switching and Routing (HPSR), 2016
[4] D. Gligoroski et al., "Minimal Header Overhead for Random Linear Network Coding," In Proceedings of IEEE International Conference on Communication Workshop (ICCW), pp. 680 - 685, June 2015

Author Response

Based on the comments, we have been studied a lot about Network coding or erasure coding while looking at the references you gave us. It will be helpful for future works. Thus, the corresponding references are added and some further study items are suggested in Section 5 (conclusion).

Thank you for the valuable comments.

The performance analysis section looks good although the error rate can be bigger than 0.3, then the performance of the proposed algorithm is expected to become worse.

Based on the comments, our further works will include the header reduction. The corresponding description is given in Section 5 of the revised paper. We also revised the Section 4 with more detailed analysis for the experimental results.

Thanks for the useful and helpful comments and suggestion.

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

The quality of the work has been significantly increased thanks to the new test campaign performed. The description of methods is significantly improved, providing a more clear comparison between CoAP-SC, CoAP over UDP, and CoAP over TCP. Furthermore, it led to clarify the limits of the work, which have been discussed in the conclusions.

In view of that, this reviewer thinks the quality of the work has been improved sufficiently to deserve the publication.
However, as a final suggestion, I would recommend the authors to provide a brief description in the Introduction why the use of CoAP (in general, not the proposed approach) is advisable for IoT compared to the use of UDP and TCP only to provide a little of the background for the reader.

Author Response

Based on the suggestion, the paper was now revised by including the description concerned with the comment (why CoAP is advisable for IoT services, rather than TCP and TCP) into the Introduction section.

Thanks for the valuable comments and suggestion!

Reviewer 2 Report

Unfortunately, i would have to reject this work, as things are still unclear to me. Specifically:

1. The authors claim that: "It is reported that the conventional transport schemes using HTTP and TCP are not suitable for delivery of IoT applications, since these protocols are too heavy and complicated
perations to support the small sensor devices in IoT networks.

Later, they claim that the CoAP uses the flow control and reliability mechanism of TCP. Then, how come CoAP is not heavy too? In what sense is it faster? The authors do not explain.

2. The triple handshake is also a burden, but without it, how can one start a flow control and reliability processes, as ACK anD SYN fields have to be exchanged. Again, this point is unclear. Are the ACK messages generated only if a data loss is detected? This is also unclear. How is the sender aware that the remaining streams arrived properly?

3. "In this figure, we can see that CoAP over UDP gives larger latency than CoAP over TCP"

This result requires more explanation. Generally, UDP is unreliable, but in cases no errors occur, it should produce smaller latencies compared to a TCP based scheme. Moreover, the general philosophy of UDP, is "send the packets without special care about resubmissions". So, how is this policy with timeout events in case of packet losses implemented?

4. In my opinion the results are not properly explained and comply to the advantages the proposed scheme is claimed to have.

Author Response

2nd Responses to Comments (Reviewer 2)

Manuscript ID: electronics-859737

The authors claim that: "It is reported that the conventional transport schemes using HTTP and TCP are not suitable for delivery of IoT applications, since these protocols are too heavy and complicated operations to support the small sensor devices in IoT networks. Later, they claim that the CoAP uses the flow control and reliability mechanism of TCP. Then, how come CoAP is not heavy too? In what sense is it faster? The authors do not explain.

Thank you very much for your valuable comments.

CoAP/UDP was initially proposed as IoT messaging protocol. As you mentioned, TCP may also be used as a good candidate for IoT services, and thus the IETF CoRE WG is now developing the CoAP/TCP. In the meantime, this paper focuses on how to enhance the CoAP/UDP by using the streaming control (CoAP-SC). We believe the proposed scheme can also be another candidate for delivery of IoT streaming data messages.

The corresponding description is now given in Section 1 and 2 of the revised paper.

The triple handshake is also a burden, but without it, how can one start a flow control and reliability processes, as ACK and SYN fields have to be exchanged. Again, this point is unclear.

As done in the legacy CoAP/UDP, the CoAP-SC scheme also begins with an initialization operation so as to arrange the resources and information required for streaming. This may be similar to the TCP 3-way handshaking operations. The corresponding description is given in Section 3.1 of the revised paper. Thanks for the helpful comments.

Are the ACK messages generated only if a data loss is detected? This is also unclear. How is the sender aware that the remaining streams arrived properly?

Based on the comments, the paper was revised. The receiver will generate an ACK message in the following three situations:

1) When the receiver does not receive any new data message for a specific time;

2) When the receiver has detected some loss of data message;

3) When the sender needs to flush the buffer.

The corresponding description is given in Section 3.2 and 3.3 of the revised paper.

"In this figure, we can see that CoAP over UDP gives larger latency than CoAP over TCP"

So, how is this policy with timeout events in case of packet losses implemented? In my opinion the results are not properly explained and comply to the advantages the proposed scheme is claimed to have.

In general, UDP provides smaller latencies than TCP and messages in UDP. However, the original CoAP-based mechanism (e.g., CoAP CON and ACK messages) tends to induce large delays in the error recovery process. In the legacy CoAP, the sender retransmits data, if it does not receive an ACK within a particular time after data transmission. In this paper, we set this time as one second. The corresponding description is given in Section 4 of the revised paper.

Overall, we believe that the paper has been enhanced with your helpful comments. Thank you very much again.

Author Response File: Author Response.pdf

Reviewer 3 Report

You have improved the manuscript. You have also addressed some well and some minimally. The contribution is still incremental and not significant enough for a journal level publication.

Author Response

Your comments are helpful to enhance the paper.

Thanks for the valuable comments and suggestion!

Reviewer 4 Report

The reviewer is satisfied with the current manuscript.

Author Response

Your comments are helpful to enhance the paper.

Thanks for the valuable comments and suggestion!

Round 3

Reviewer 2 Report

Unfortunately the response i get is still insufficient and not convincing. For example,

Reviewer's Comment 1>

Thank you very much for your valuable comments.

The corresponding description is now given in Section 1 and 2 of the revised paper.

In the text, the description says: To overcome these problems, we propose a CoAP-based streaming control (CoAP-SC), which is
an extension of CoAP over UDP with error handling and flow controls for throughput enhancement.
The proposed scheme is designed by considering the sequence number of data message, the use of
ACK messages, and the buffer size of the sending buffer.

Again the question remains: In what sense is the proposed scheme faster?

The triple handshake is also a burden, but without it, how can one start a flow control and reliability processes, as ACK and SYN fields have to be exchanged. Again, this point is unclear.

Here, if the triple handshake is used, this is a burden so how is the proposed scheme efficient as it uses mechanisms that cause overheads. On the other side, without it, it is impossible to have reliable transmissions.

Also, comment 3 and 4 are not addressed in a satisfactory manner and i am not convinced at all.

Author Response

In the text, the description says: To overcome these problems, we propose a CoAP-based streaming control (CoAP-SC), which is an extension of CoAP over UDP with error handling and flow controls for throughput enhancement. The proposed scheme is designed by considering the sequence number of data message, the use of ACK messages, and the buffer size of the sending buffer.

Again the question remains: In what sense is the proposed scheme faster?

Thank you for the valuable comment. It is noted that the existing CoAP/UDP scheme gives a simple CON and ACK mechanism for reliability, whereas the proposed CoAP-SC/UDP scheme provides a more elaborated streaming control mechanism by considering the sequence number of data message, the use of ACK messages, and the buffer size of the sending buffer. This tends to give better performance, in particular, in the networks with data losses, as shown in Figure 21 and Figure 23 of Section 4.

The corresponding description is now given in Section 2 of the revised paper.

We fully agree with the comment. A more reliable and efficient scheme will require the corresponding additional overhead. We note that in the proposed scheme, the initialization operations for exchanging some new streaming control parameters are used in the same way with the existing CoAP/UDP, as described in Section 3.1. The additional overhead will come only from the management of the concerned parameters (such as sequence number, ACK number, etc) at each end node.

In conclusion, the existing CoAP/UDP and CoAP/TCP schemes can be used for reliable services. However, the proposed scheme may also be considered as a candidate scheme for real-time streaming services, in particular, in the IoT networks with some data losses, with small overhead for management of the associated parameters, such as SN and AN, etc.

The corresponding description is now given in Section 5 of the revised paper.

Thanks for the valuable comments.

Author Response File: Author Response.pdf

Reviewer 3 Report

I guess the paper can be accepted for publication in its current form.

Author Response

The paper has been enhanced with your helpful comments. Thank you very much again.

Article Menu

CoAP-Based Streaming Control for IoT Applications

Further Information

Guidelines

MDPI Initiatives

Follow MDPI