Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Must, Should, Don't Care: TCP Conformance in the Wild

arxiv.org

Post reply on HN
Print view View original

11–20 of 53 posts

Re: Must, Should, Don't Care: TCP Conformance in the Wild

#11

Post by Disposition »

Eikon wrote: post #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.

That wouldn't work too well with complex RFCs like X509, should is used for some backwards compatibility to earlier RFC revisions and many optional elements that would fragment the standard into dozens of extensions.

IMHO implementors must implement a "should", not in the same sense of the binding requirement that "must" presents, but as a boolean possibility; the element may not be present, but it should never be ignored in a way that would break implementations making use of it.

Re: Must, Should, Don't Care: TCP Conformance in the Wild

#13

Post by IceDane »

asdfasgasdgasdg wrote: post #6
iwalton3 wrote: post #5

This 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.

I think you're both right.

He's still right because my experience suggests that it is 100% likely that somewhere, some system relies on a bug in the TCP protocol stack of another system causing a segfault to shut down something critical.

Re: Must, Should, Don't Care: TCP Conformance in the Wild

#14

Post by brudgers »

Eikon wrote: post #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.

RFC's are consensus documents. The optional parts address the concerns of stakeholders with existing products. This is an alternative to their veto or non-participation in the standards development process or development of competing standards for business survival.

Re: Must, Should, Don't Care: TCP Conformance in the Wild

#15

Post by dagenix »

dirtydroog wrote: post #12

HTTP is in a similar sorry state. For example, it offers pipelining support but nobody can reliably use it because it probably won't work on some forgotten about machine somewhere on the path.

Pipelining support in http 1.1 is basically useless even outside of the compatibility issues.

Re: Must, Should, Don't Care: TCP Conformance in the Wild

#16

Post by kevingadd »

asdfasgasdgasdg wrote: post #3

To 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 p…

The downside to QUIC is that all the other nodes in the chain lose the ability to do useful things. Of course in the long run it's turned out that Google et al do not want anyone else doing useful stuff, but for quite a while it was very useful to be able to have stuff in the middle like a caching proxy. Alas, that era is over.

As an admin it's appealing to be able to have stuff like deep packet inspection to give me info on network traffic, but the price we pay collectively for that being possible is way too high so it was inevitable we'd lose it.

Re: Must, Should, Don't Care: TCP Conformance in the Wild

#17

Post by rkeene2 »

dagenix wrote: post #15
dirtydroog wrote: post #12

HTTP is in a similar sorry state. For example, it offers pipelining support but nobody can reliably use it because it probably won't work on some forgotten about machine somewhere on the path.

Pipelining support in http 1.1 is basically useless even outside of the compatibility issues.

I built a server-side mouse tracking over HTTP application that used HTTP/1.1 Pipelining to increase precision [0], back when web browsers supported HTTP/1.1 Pipelining, that is.

[0] https://github.com/rkeene/webdraw

Re: Must, Should, Don't Care: TCP Conformance in the Wild

#20

Post by ninju »

IceDane wrote: post #13
asdfasgasdgasdg wrote: post #6

Earlier quoted context omitted.

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.

I think you're both right. He's still right because my experience suggests that it is 100% likely that somewhere, some system relies on a bug in the TCP protocol stack of another system causing a segfault to shut down something critical.

https://xkcd.com/1172/

(leave your mouse over the image and read the hover text :-))

Post reply on HN