Hi Abhijan, (Keeping the lists included as destinations, sorry for multiple copies...)
Thank you very much for your feedback. Please find some inline comments below: > Hi, > > Section 3.4 of the draft states the following: > > "it is envisaged that further segment exchanges will take place within an > interval of two hours since the last segment has been sent" Actually, the complete sentence is: 'In CNNs, a TCP connection SHOULD be kept open as long as the two TCP endpoints have more data to exchange or it is envisaged that further segment exchanges will take place within an interval of two hours since the last segment has been sent.' So the 'as long as' still precedes the sentence you have pointed out. Anyway, prepending an 'if' to the sentence may help clarify the text. By the way, the two-hour value (influenced by the default keep-alive timer) was chosen here as a trade-off between avoiding too frequent TCP connection establishment overhead and avoiding to keep unused state in constrained devices for too long. > Could you please explain a bit about the basis of such a deterministic > assumption? If you could share some pointers to any study related to this. > There is RFC 5382 which kind of mandates that the time out cannot be less > than 124 minutes. Does it drive the above assumption? However, not sure > how many implementations adheres to the time mentioned in RFC 5382. RFC 5382 (which is very relevant for this draft) requires NATs not to remove state for a live connection, ensuring that 'applications can send keep-alive packets at the default rate (every 2 hours)'. So the two-hour default keep-alive timer is also influencing the 124-minute time out mentioned in RFC 5382. > In the recent time I had been looking at the different efforts that has > gone into improving TCP performance from different aspects under different > circumstances since the early days. Given the short transactional type of > exchanges, would it be also worthwhile to count experimental RFCs like > "TCP Fast Open" and see how CoAP performs on top of it? I agree that this is something to look at. TCP Fast Open allows data to be carried in the SYN (and SYN-ACK) packet(s) and consumed by the receiving end during the initial connection handshake. However, TCP Fast Open involves an initial RTT for requesting a 4-to-16-byte cookie, which is then included in the Fast Open option of the SYN segment of new connections. Furthermore, the cookie needs to be updated (I'm not sure how often) for security. TCP Fast Open can benefit applications that open 'many' new connections, while the approach proposed in our draft is to keep a TCP connection open for long time, avoiding connection establishment as much as possible. If a TCP connection is kept open for long time, the possible benefits (which, in my opinion, are not so clear considering all of the above) of TCP Fast Open will become asymptotically negligible. Cheers, Carles > Regards > Abhijan Bhattacharyya _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
