Hi Carles, > On 21 Jun 2016, at 10:38, Carles Gomez Montenegro <[email protected]> > wrote: > > Hi Ari, > > Thank you very much for your feedback, and sorry for the late response. > Please find below a few inline comments: > >>> 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! >> >> I like the simplicity too and would envision using that in cases where I'm >> using TCP for middlebox traversal cases. On the other hand, when doing >> something like firmware update for not-that-constrained device over long >> RTT link, this restriction could bite back big time. That makes me wonder >> if it would make sense to be able to indicate the capability for doing >> window bigger than 1 e.g., in RD registration. > > I see your point... > > Yes, firmware updates may suffer from a stop-and-wait behaviour (specially > for high RTT scenarios). > > On the other hand, how are firmware updates being done today? > (Is it that e.g. CoAP with block is used over UDP, which would be > stop-and-wait by default, or are people using 'enhanced' settings such as > NSTART > 1?)
Perhaps experience from the IoTSU workshop could provide some data on this? > If TCP with a window of one segment is used, performance would be > relatively similar to that of CoAP (with NSTART=1) over UDP (although the > CoAP/TCP headers are larger than CoAP/UDP headers). True. What I'm thinking is that if we describe in this document how simple implementation can stay simple with small window regardless of the capabilities of the other endpoint, then we don't need the MUST here. Cheers, Ari _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
