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" 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. 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? 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 ____________________________________________ From: "Carles Gomez Montenegro" <[email protected]> To: "Carsten Bormann" <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected] Extensions" <[email protected]>, "[email protected]" <[email protected]>, "[email protected] WG" <[email protected]> Date: 06/10/2016 08:40 PM Subject: Re: [core] [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] Sent by: "core" <[email protected]> Hi Carsten, Thanks a lot for your comments. While we work to address those, it would be really helpful if folks that have faced 'bad constrained TCP implementations', and/or have struggled with middlebox traversal can share their experience. Cheers, Carles > Carles, > > thanks for submitting this. > > I think that this draft is truly best handled in LWIG. > > We don't *have* to profile TCP for CoAP-over-TCP; people are free to use > whatever parts of TCP they think are useful. (And, of course, there are > applications for CoAP-over-TCP that are in the backend.) > > On the other hand, it is useful to > -- manage expectations: > what can I expect that the *other* side will offer in TCP functionality > -- give advice to implementers: > what is useful to implement, what not > -- collect implementation experience that is relevant for these two > > (One interesting effect I'm seeing is that people know how good TCP can > be, which shapes their expectations, but then they are hurt by using > really bad constrained TCP implementations... We certainly should be > paying attention to this on the CoRE WG side.) > > My biggest comment is probably that for device-to-cloud, the level of > TCP functions implemented will be asymmetric (full TCP on cloud side, > possibly more limited on the device side) -- what is the effect of this > asymmetry? > > Maybe there also needs to be more discussion on the role of the > middlebox (after all, we are doing CoAP-over-TCP to devices for the sole > reason to climb over middleboxes). > > Grüße, Carsten > > > Scharf, Michael (Nokia - DE) wrote: >> Heads-up >> >> Michael >> >> >> -----Original Message----- >> From: Lwip [mailto:[email protected]] On Behalf Of Carles Gomez >> Montenegro >> Sent: Friday, June 10, 2016 11:36 AM >> To: [email protected] >> Cc: [email protected] >> Subject: [Lwip] [Fwd: New Version Notification for >> draft-gomez-core-tcp-constrained-node-networks-00.txt] >> >> Dear LWIG WG, >> >> /** Apologies for possibly multiple similar e-mails... **/ >> >> We have just submitted the draft entitled 'TCP over Constrained-Node >> Networks', which we believe may be of interest to the members of this >> group. >> >> We would like to kindly ask for feedback, specially on the basis of >> implementation experience. >> >> Thank you very much! >> >> Kind regards, >> >> The authors >> >> >> ---------------------------- Original Message >> ---------------------------- >> Subject: New Version Notification for >> draft-gomez-core-tcp-constrained-node-networks-00.txt >> From: [email protected] >> Date: Fri, June 10, 2016 10:38 am >> To: "Jon Crowcroft" <[email protected]> >> "Carles Gomez" <[email protected]> >> -------------------------------------------------------------------------- >> >> >> A new version of I-D, >> draft-gomez-core-tcp-constrained-node-networks-00.txt >> has been successfully submitted by Carles Gomez and posted to the IETF >> repository. >> >> Name: draft-gomez-core-tcp-constrained-node-networks >> Revision: 00 >> Title: TCP over Constrained-Node Networks >> Document date: 2016-06-10 >> Group: Individual Submission >> Pages: 9 >> URL: >> https://www.ietf.org/internet-drafts/draft-gomez-core-tcp-constrained-node-networks-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-gomez-core-tcp-constrained-node-networks/ >> Htmlized: >> https://tools.ietf.org/html/draft-gomez-core-tcp-constrained-node-networks-00 >> >> >> Abstract: >> This document provides a profile for the Transmission Control >> Protocol (TCP) over Constrained-Node Networks (CNNs). The >> overarching goal is to offer simple measures to allow for lightweight >> TCP implementation and suitable operation in such environments. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> Lwip mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lwip >> >> _______________________________________________ >> tcpm mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ core mailing list [email protected] https://www.ietf.org/mailman/listinfo/core =====-----=====-----===== 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
