Hi Zhen, Thanks for your feedback!
(And sorry for the late response...) > On Mon, Jun 13, 2016 at 5:57 PM, Carles Gomez Montenegro > <[email protected]> wrote: >>> >>>> 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! > > Which way is better in this case, sending two and sleep, or sending > one followed by another? Sometimes the former will be better for > constrained nodes. In that specific case, if the constrained device is sleeping by default, there could be energy consumption overhead due to the wake up before communication, plus the cool down after communication. In that case, it would be more energy efficient to wake up, send the two messages consecutively, receive the ACK(s) and then go back to sleep, as you point out (otherwise, the energy consumption overhead would be duplicated). So this is an additional possible benefit of using a window size greater than one, although it may add complexity to implementations. Cheers, Carles _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
