Hi Carles, Thank you for the explanations. Just couple of observations:
> 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. That is understood. The point is that, there is an element of doubt regarding whether the implementations in reality abide by the given time interval or silently times out without the knowledge of the end-points. > 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. Keeping TCP session active for long time may be definitely useful for certain cases. But again, there is the additional draining of energy due the keep alive mechanism. Also, as IoT end-points may like to conserve energy by opportunistic sleeping, maintaining TCP connection for too long may be difficult and TFO kind of approach, though designed for browsers, may be useful. So a study in this line may help. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Mailto: [email protected] Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ "Carles Gomez Montenegro" <[email protected]> wrote on 06/21/2016 04:17:13 PM: > From: "Carles Gomez Montenegro" <[email protected]> > To: "Abhijan Bhattacharyya" <[email protected]> > Cc: "[email protected]" <[email protected]>, > "[email protected]" <[email protected]>, "[email protected] Extensions" > <[email protected]>, [email protected] > Date: 06/21/2016 04:17 PM > Subject: Re: [core] [tcpm] [Lwip] [Fwd: New Version Notification for > draft-gomez-core-tcp-constrained-node-networks-00.txt] > > 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 > > =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
