Must, Should, Don't Care: TCP Conformance in the Wild • Hacker News Board

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

#21

Post by kevin_thibedeau » Sun, Apr 05, 2020, 4:30 PM UTC

kevingadd wrote: post #16

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…

The upside to QUIC is that all the other nodes in the chain lose the ability to do useful things.

This behavior is why we can't use SCTP everywhere and can't deploy new protocols on top of IP.

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

#22

Post by beojan » Sun, Apr 05, 2020, 4:45 PM UTC

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.

> In my opinion, RFCs should strive to limit the optional parts of a specification at a minimum

If only USBIF had done that

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

#23

Post by slezyr » Sun, Apr 05, 2020, 5:01 PM UTC

Diggsey wrote: post #9

Maybe part of developing a standard should be developing and maintaining test and validation suites for that standard...

That's a good idea that's already implemented

https://www.khronos.org/vulkan/adopters/

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

#24

Post by asdfasgasdgasdg » Sun, Apr 05, 2020, 5:06 PM UTC

kevingadd wrote: post #16

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…

Yeah, what's useful today will be ossified in ten or twenty years. That's kind of the point I was making (which you note in your second paragraph). If you want a healthy ecosystem you have to remove the ability of economically-disconnected middlemen to screw with your protocol. And the best way to do that is to make it as dead simple as possible, so there is very little leeway in implementation.

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

#25

Post by amscanne » Sun, Apr 05, 2020, 5:25 PM UTC

oconnor663 wrote: post #7

Is there a standardized set of TCP "test vectors" anywhere? Even an informal de facto standard test like what SSLLabs is for TLS?

There are commercial conformance tests.

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

#26

Post by touisteur » Sun, Apr 05, 2020, 5:39 PM UTC

kevin_thibedeau wrote: post #21

kevingadd wrote: post #16

Earlier quoted context omitted.

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…

The upside to QUIC is that all the other nodes in the chain lose the ability to do useful things. This behavior is why we can't use SCTP everywhere and can't deploy new protocols on top of IP.

But I thought you could use SCTP over UDP (works, I tried). If QUIC is another layer above SCTP it feels like wasted effort. SCTP is really interesting and featureful. Multi-homing, parallel streams, datagram oriented...

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

#27

Post by Dosenpfand » Sun, Apr 05, 2020, 5:48 PM UTC

oconnor663 wrote: post #7

Is there a standardized set of TCP "test vectors" anywhere? Even an informal de facto standard test like what SSLLabs is for TLS?

There is Google's packetdrill: https://github.com/google/packetdrill

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

#28

Post by toast0 » Sun, Apr 05, 2020, 5:56 PM UTC

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.

Pipelining in 1.1 has some issues, but it could be useful in the right circumstances (except that, there's not a lot of implementations of pipelining, so chances are the other end won't do it).

The perfect use case for pipelining is when the client is connected to a (reverse) proxy near to it, is making retryable requests, the origin is far from the proxy, and the requests don't take much time for the origin to process.

You can also get benefits if there is a proxy near the server and the requests take significant time to process, but the proxy can divide them over multiple servers (or the server handles pipelining and divides over multiple threads).

The way these usecases are met instead is through multiple TCP connections, or multiple multiplexed streams in HTTP/2 (and beyond). There's certainly benefits of individual streams, but there's costs too, so it's unfortunate that the http/1.1 way was stiffled.

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

#29

Post by codetrotter » Sun, Apr 05, 2020, 6:09 PM UTC

ninju wrote: post #20

IceDane wrote: post #13

Earlier quoted context omitted.

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 :-))

I’m on mobile, what does the alt text say again?

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

#30

Post by detaro » Sun, Apr 05, 2020, 6:11 PM UTC

codetrotter wrote: post #29

ninju wrote: post #20

Earlier quoted context omitted.

https://xkcd.com/1172/ (leave your mouse over the image and read the hover text :-))

I’m on mobile, what does the alt text say again?

https://m.xkcd.com/1172/ > There are probably children out there holding down spacebar to stay warm in the winter! YOUR UPDATE MURDERS CHILDREN.