Toerless Eckert writes: > If insights like there would be documented more prominentaly, like > in a living IETF document, then they would fsater trickle through > implementers.
That kind of things were usually found in the interop events where there were few dozen vendors testing againt each other. We did document some of those issues in documents like RFC4718 IKEv2 Clarifications and Implementation Guidelines. Most vendors are not very keen on telling how they actually manage to get the performance gains they do, because that is one of their benefits, if they are 3% faster than competitor because they actually modify operating system so that it always makes sure there is space at the end of packet for ICV. It is much easier to get vendors to disclose, issues that affect interoperability than issues that affect performance. And even those cases they do no want company names to be mentioned. They might tell their secret performance enhancing tricks during friendly talk with other implementor, but might not want this to be written down (as then they would need permission from the management, which would most likely say no way). > > So immediately when the options to use start to depend on the > > platform, implementation etc it gets harder and harder to find out > > which will be the optimal combination between two devices, and they > > might end up using suboptimal feature set. And all of those add more > > complexity and combinations that needs to be tested. > > Before the next profile changes as to what options SOULD/MUST be supported, > there could be a collection round of evidence: If a new protocol option > has documented performance results in comparison to prior MUST options > that show e.g.: double performance, you will have a hard time to reject > it. If it doesn't have such data, you will have an easy way to reject it. If there would be someone who finds a way to double the performance then yes, that would be huge difference, but when we are talking implementations which should be able to use 95% of the capacity of the network link anyways, the performance gains are usually much smaller. For large packets the speed is usually restricted either by the network speed, or the raw crypto speed. For small packets the issues are quite often in general operating system overhead (i.e., even without crypto things tend to be slow). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
