Must, Should, Don't Care: TCP Conformance in the Wild
1–10 of 53 posts
Re: Must, Should, Don't Care: TCP Conformance in the Wild
#2"Should" and "May" are such horrible words to encounter when implementing an RFC.
Sometimes, implementing workarounds for ends that only implements "Must" is harder than just implementing the RFC as if everything was just mandatory.
In my opinion, RFCs should strive to limit the optional parts of a specification at a minimum and, maybe, put the remaining in extensions.
Re: Must, Should, Don't Care: TCP Conformance in the Wild
#3To me, this says a lot about expectations of conformance when many different entities need to implement the same spec. As the size of the spec or the number of entities grow, the probability of nonconformance approaches one. Then you end up with two specs: the ivory tower one, and the usable, actually implemented, lowest common denominator one.
This problem seems especially acute when there are multiple hops on the path that are able to interpret (and fuck up with) data flowing through that hop. Especially when the owners of those hops don't have a direct economic connection to the entities dealing with their failures.
This seems to argue in favor of something like QUIC. You use an extremely simple protocol for the transport (basically, "try to send this data to that address"). You hide the complex parts of the protocol in an encrypted channel so that only the economically connected stakeholders have to conform. This aligns incentives better than in the case of TCP and probably gives you better outcomes in the long run.
Re: Must, Should, Don't Care: TCP Conformance in the Wild
#4I can understand why someone implementing - say - a custom web server stack might never have encountered a TCP packet with the URGent bit set. As I understand it, it's only really used by telnet (does ssh use it?)
Re: Must, Should, Don't Care: TCP Conformance in the Wild
#5This reminds me of "Hyrum's Law":
"With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody."
People might implement work-arounds for bugs in an API that could break when the underlying bug is fixed. Or software might implement the absolute bare minimum for it to "work" with some specific implementation.
Re: Must, Should, Don't Care: TCP Conformance in the Wild
#6This reminds me of "Hyrum's Law": "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." People might implement work-arounds for bugs in an API that could break when the underlying bug is fixed. Or software might implement the absolute bare minimum for it to "work" with some specific implementation.
This is kind of the opposite of Hyrum's law, actually, in that the protocol promises one behavior but what's actually universally supported in the wild is only a subset of that promise.
Re: Must, Should, Don't Care: TCP Conformance in the Wild
#7Is there a standardized set of TCP "test vectors" anywhere? Even an informal de facto standard test like what SSLLabs is for TLS?
Re: Must, Should, Don't Care: TCP Conformance in the Wild
#8Its going to be specific stacks that don't do the MUSTs.
Re: Must, Should, Don't Care: TCP Conformance in the Wild
#9Maybe part of developing a standard should be developing and maintaining test and validation suites for that standard...
Re: Must, Should, Don't Care: TCP Conformance in the Wild
#10"Should" and "May" are such horrible words to encounter when implementing an RFC. Sometimes, implementing workarounds for ends that only implements "Must" is harder than just implementing the RFC as if everything was just mandatory. In my opinion, RFCs should strive to limit the optional parts of a specification at a minimum and, maybe, put the remaining in extensions.
Funny how your comment also use "should" and "may" :)
Anyway, those key words are used to allow flexibility in the implementation. Remember that a RFC is specific to a single version of a single protocol.
Thus splitting everything in multiple RFCs will still implies complexity in the implementation, just not the same kind of complexity (what versions to use and when?).
> Imperatives of the type defined in this memo must be used with care and sparingly. > In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions)
> For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.