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

41–50 of 53 posts

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

#41

Post by Animats »

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…

I was at an aerospace company. In aerospace, specs matter, because part A has to plug into part B. You can remove the Pratt and Whitney engines from an airliner and substitute Rolls-Royce engines. One is not emulating the other; they both meet the same spec. DoD used to be big on having multiple sources, all making interchangeable units to the same spec.

We used to say, "if A won't work with B, check the spec. If A doesn't match the spec, A is broken. If B doesn't match the spec, B is broken. If you can't tell, the spec is broken.

Much of this worked in the early TCP/IP days because DoD was funding most of the players, both industrial and academic. They wanted interoperabilty.

There's much less of that today. Compatibility tends to involve reverse engineering the dominant player's product.

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

#42

Post by dagenix »

toast0 wrote: post #28
dagenix wrote: post #15

Earlier quoted context omitted.

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 proce…

In both of those cases it's also important that the responses be small, since, due to pipelining requiring that responses come back in the same order as requests, you have to buffer up any responses that become ready out of order. Also, the response time for each request needs to be about the same or you have to issue requests in the right order, or, you end up potentially blocking every response due to the first one taking the longest.

HTTP pipelining isn't largely unimplemented because people were lazy - its largely unimplemented because its easy to DOS a server, possibly by accident, and there are significant latency issues due to head-of-line blocking with slow requests.

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

#43

Post by dagenix »

rkeene2 wrote: post #17
dagenix wrote: post #15

Earlier quoted context omitted.

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

That does sound pretty cool. But it sounds like a fairly special case where the responses were likely uniformly small, which is unusual for a more general use case. Given somewhat more recent technology, it sounds like a great use case for something like WebSockets.

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

#44

Post by dodobirdlord »

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.

Expressed a different way, my take is that non-"must" clauses of an RFC should be cleanly severable, i.e. you could literally cut them out of the document and everything else would still make sense. How a full implementation handles interoperating with an implementation that declines an optional feature should be defined in the same place as the optional feature. Further, being able to interoperate with an implementation that declines an optional feature should be required at the same optionality level as the optional feature. It shouldn't be a "must" to support interoperability with an implementation that has declined to implement a "should". This has basically the same effect as pushing optional parts into extensions. There's the core RFC that defines the spec, and a bunch of optional features that two implementations can use by mutual agreement.

To address some common concerns about the effect this would have on general interoperability, keep in mind that a clause that reads "In scenario Foo, implementations should do X and should not do Y, but may do Z" can be much more cleanly expressed as "In scenario Foo, implementations must do X or do Y or do Z".

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

#45

Post by tialaramex »

touisteur wrote: post #40
pas wrote: post #31

Earlier quoted context omitted.

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 i…

> What's missing in SCTP (used everywhere in telephony/3-4-5g, right?) that we had to reinvent another complete transport+session layer ?

SCTP isn't encrypted. Because "Pervasive Monitoring is an Attack" new IETF protocols should be encrypted or explain why they can't be. HTTP/2 for example is in effect always encrypted (the document explains how one could in theory build an unencrypted variant but nobody implements that).

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

If you "just" drop the encrypted transport on top you either have to do all the work to deliver features like substreams yet again, or else all the metadata in the layer that's not encrypted is left unprotected and you'll regret that.

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

#46

Post by toast0 »

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.

> maybe MP-TCP will land first and then who knows.

I'm not a fan of Apple, but they've deployed MP-TCP in iOS. I'm not an iOS developer, but it looks relatively simple to enable if you're already using NSURLSession [1]. Having a server to talk to is another thing, of course. :)

[1] https://developer.apple.com/documentation/foundation/nsurlse...

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

#47

Post by nitrogen »

tialaramex wrote: post #45
touisteur wrote: post #40

Earlier quoted context omitted.

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 i…

> What's missing in SCTP (used everywhere in telephony/3-4-5g, right?) that we had to reinvent another complete transport+session layer ? SCTP isn't encrypted. Because "Pervasive Monitoring is an Attack" new IETF protocols should be encrypted or explain why they can't be. HTTP/2 for example is in effect always encrypted (the document explains how one could in theory build an unencrypted variant but nobody implements…

In addition to that I believe I've read that SCTP can't traverse all of the networks that TCP and UDP can, so any universal datagram protocol will have to build on UDP.

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

#48

Post by rkeene2 »

dagenix wrote: post #43
rkeene2 wrote: post #17

Earlier quoted context omitted.

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

That does sound pretty cool. But it sounds like a fairly special case where the responses were likely uniformly small, which is unusual for a more general use case. Given somewhat more recent technology, it sounds like a great use case for something like WebSockets.

Yeah, WebSockets would also work here -- I would need to invent an ad-hoc protocol for making the resource requests, and it would be similar to a mini HTTP/1.1 Pipelining in spirit.

The project needs some other work, since it looks like changes to Chrome have broken the mouse tracking. [0]

http://webdraw.rkeene.org/

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

#49

Post by touisteur »

tialaramex wrote: post #45
touisteur wrote: post #40

Earlier quoted context omitted.

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 i…

> What's missing in SCTP (used everywhere in telephony/3-4-5g, right?) that we had to reinvent another complete transport+session layer ? SCTP isn't encrypted. Because "Pervasive Monitoring is an Attack" new IETF protocols should be encrypted or explain why they can't be. HTTP/2 for example is in effect always encrypted (the document explains how one could in theory build an unencrypted variant but nobody implements…

Ah, encryption, thanks.

Thought there was a sctp+tls RFC https://tools.ietf.org/html/rfc3436

don't know whether any userland lib supports this with sctp-over-UDP.

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

#50

Post by petercooper »

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…

On the latter topic, one of my favorite ever weblogs was that of Nat Friedman, now CEO of GitHub. Excluded from the Wayback Machine and gone forever (unless he kept a personal archive, I guess), but a lot of the stuff in the 2000-2010 era covered some very interesting technologies he was involved with building.
Post reply on HN