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

31–40 of 53 posts

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

#31

Post by pas »

touisteur wrote: post #26
kevin_thibedeau wrote: post #21

Earlier quoted context omitted.

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

QUIC is basically SCTP over UDP. It has substreams (like HTTP/2, but it eliminates the TCP level head-of-line blocking), there's a multipath extension (proposal from 2018) - but maybe MP-TCP will land first and then who knows.

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

#32

Post by Animats »

This takes me back to the early days of TCP, when I used to do this. I had a TCP implementation with a "bit bucket"; every packet that was either rejected or didn't advance the connection (such as a duplicate) was logged. Then I'd send out emails to other developers; "Your packet sent at T did not conform to spec, per para..." Gradually, things got better.

The "urgent" option could be deprecated. The original purpose was for when a TELNET connection was sending data to a slow printing terminal such as a Teletype, and you wanted to cancel the output. The TCP connection was being held back by flow control waiting for the printer on output, and might be held back on input if you'd typed ahead but the server wouldn't take another line until the output was done. The user would push BREAK, the TCP connection would send an urgent message, bypassing any queued data, and the server would get this, stop sending, and clear its output queue.

Almost nobody has needed that feature in this century. But there's probably someone, somewhere, with some ancient embedded device like a cash register printer, using it.

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

#33

Post by kstenerud »

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.

It's remarkably difficult to avoid "should" and "may" in any decently sized spec. I count 11 "shoulds" in [1] and 7 in [2], and I tried REALLY hard to keep them to a minimum :/

[1] https://github.com/kstenerud/concise-encoding/blob/master/ct...

[2] https://github.com/kstenerud/concise-encoding/blob/master/cb...

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

#34

Post by cryptonector »

rwmj wrote: post #4

I 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?)

SSH does not use it.

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

#35

Post by peterwwillis »

Name a standard with 3 or more implementations and at least one of them will have violated the standard. Sometimes it's all three. Sometimes it's the implementation of the people who wrote the standard.

This is inherent to all standards implemented by different products. There's no implementation police going around checking on and forcing people to implement standards properly. And in the course of just regular product development, it often starts to slowly violate the standard without notice.

It sure does help when there's a test suite that you can validate your implementation against, but I find them rare.

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

#36

Post by battery_cowboy »

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.

Every international spec I've read contains should and may, but also includes must here and there.

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

#37

Post by tptacek »

Animats wrote: post #32

This takes me back to the early days of TCP, when I used to do this. I had a TCP implementation with a "bit bucket"; every packet that was either rejected or didn't advance the connection (such as a duplicate) was logged. Then I'd send out emails to other developers; "Your packet sent at T did not conform to spec, per para..." Gradually, things got better. The "urgent" option could be deprecated. The original purpose…

FTP used URG too, but then, FTP is itself a deprecated monstrosity.

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

#38

Post by lkrubner »

Animats wrote: post #32

This takes me back to the early days of TCP, when I used to do this. I had a TCP implementation with a "bit bucket"; every packet that was either rejected or didn't advance the connection (such as a duplicate) was logged. Then I'd send out emails to other developers; "Your packet sent at T did not conform to spec, per para..." Gradually, things got better. The "urgent" option could be deprecated. The original purpose…

Mark Pilgrim once had a hilarious blog post in which he argued that all software developers were either assholes are psychopaths. He also argued that some people believed in angels, who followed the specs for the best of reasons, but who were actually mythical. Your """"Your packet sent at T did not conform to spec, per para..." Gradually, things got better""" would make you an angel, as you did it for the right reasons, though I imagine some of the people you wrote gave you a different classification.

Sadly, Mark Pilgrim committed info-suicide and erased everything he'd written from the Web. (Off topic: it is sad how much disappears from the Web, and how many weblogs shut down. Some of the best essays I've ever read were on weblogs, now gone. I just revived a weblog I had run in 2005, and checking the links I found that the linkrot was running in the area of 50% to 60%.)

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

#39

Post by jgraham »

lkrubner wrote: post #38
Animats wrote: post #32

This takes me back to the early days of TCP, when I used to do this. I had a TCP implementation with a "bit bucket"; every packet that was either rejected or didn't advance the connection (such as a duplicate) was logged. Then I'd send out emails to other developers; "Your packet sent at T did not conform to spec, per para..." Gradually, things got better. The "urgent" option could be deprecated. The original purpose…

Mark Pilgrim once had a hilarious blog post in which he argued that all software developers were either assholes are psychopaths. He also argued that some people believed in angels, who followed the specs for the best of reasons, but who were actually mythical. Your """"Your packet sent at T did not conform to spec, per para..." Gradually, things got better""" would make you an angel, as you did it for the right reas…

http://web.archive.org/web/20051016203842/http://diveintomar...

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

#40

Post by touisteur »

pas wrote: post #31
touisteur wrote: post #26

Earlier quoted context omitted.

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

QUIC is basically SCTP over UDP. It has substreams (like HTTP/2, but it eliminates the TCP level head-of-line blocking), there's a multipath extension (proposal from 2018) - but maybe MP-TCP will land first and then who knows.

Thanks for this answer but I still don't understand, sorry.

What's missing in SCTP (used everywhere in telephony/3-4-5g, right?) that we had to reinvent another complete transport+session layer ? It's already in the kernel, seems to have had its own share of CVEs that it should now be relatively trustable? But it's also available in userland, especially over UDP.

Performance is fine, from my benchmarks. Ease of use is (to me) far better than TCP and all the socket-hand-holding you need to do (if you don't use zmq because tired of writing the same all the time). Flexibility of substreams is amazing. Multi-homing is great so you can bond links at the applicative level (so, higher decoupling instead of ip-bonding).

I'm genuinely curious as to why they haven't just taken SCTP as is, and added the extensions (?) they need.

Post reply on HN