Hi Zhen, Thanks a lot for your support and comments!
Please find below some inline responses. > Hi Carles, > > Nice draft. I always want to know the complains of TCP problems over > Constrained link and device. In the very beginning of Lwig, the > IETF79 bof, David Bormann gave an excellent talk about similar issues > ( i try to search the IETF proceedings for the talk but failed coz > they do not hold it for informative bof ). But we failed to collect > these information from implementer or researchers like you further on. > Thanks again for this always timely work. > > In this respect, I agree with Carsten that your draft being handled in > lwig and a talk is welcome at Berlin meeting. Thanks a lot. We'll prepare a presentation for Berlin, and will also change the name of the draft to show 'lwig' instead of 'core'. > Some quick comments for your draft. > >>3.2. Window Size > >> A TCP window size of one segment follows the same rationale as the >> default setting for NSTART in [RFC7252], leading to equivalent >> operation when CoAP is used over TCP. > > IMHO, it does not matter because if the application has only a short > message to send, the de facto effective cwnd will be ONE. I understand that what you point out may happen in many cases... However, a device, in some cases, might want to send e.g. two (or more) packets back to back to the same destination. In those, the window size of one would make a difference. By the way, currently the phrasing in the draft is that a window size of one 'MUST' be used. This keeps a behavior equivalent to that of CoAP for confirmable messages in RFC 7252, and dramatically simplifies implementations. However, I wonder if some more freedom should be offered, and maybe the 'MUST' could become a 'SHOULD', at the expense of opening the door to greater complexity... I personally tend to prefer the first approach, but it would be great to receive more feedback on this! >>3.3. RTO estimation >> challenges of CNNs, in contrast with the RFC 6298 RTO. Therefore, as >> per this document, CoCoA RTO SHOULD be used in TCP over CNNs. >> Alternatively, implementors MAY choose the RTO estimation algorithm >> defined in RFC 6298. One of the two RTO algorithms MUST be >> implemented. > > Is the RTO estimation algorithm link-specific? For example, I knew you > have some work on CoCoA over GPRS. Is it always better than the > competitor? These are crucial questions. In our work with CoCoA (e.g. [1]), we have used: - GPRS/UMTS emulation - GPRS testbed experiments - IEEE 802.15.4 (with and without L2 reliability) simulation - IEEE 802.15.4 testbed experiments In fact, using different link layer setups has been fundamental to identify issues of the initial CoCoA version, and to properly fine-tune it. While in some specific experiments (i.e. combination of network topology, offered load, traffic pattern, etc.) an alternative algorithm has shown better performance, in the more recent versions of CoCoA: - CoCoA has never underperformed default CoAP (while alternative algorithms have in some scenarios). - CoCoA shows a performance at least similar to, often better than, that of default CoAP. We evaluated performance in terms of parameters such as throughput, retry ratio, settling time after a burst of messages, and fairness. Nevertheless, of course, we welcome more feedback from other evaluation scenarios! Cheers, Carles [1] Here is our most mature paper on the topic: https://www.researchgate.net/publication/297989374_CoAP_Congestion_Control_for_the_Internet_of_Things > Cheers, > Zhen _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
