3 ms·

> I concur that the TCP is damn hard. It's just that you can't expect that "everybody else" is perfect. There is no evidence that he expected everyone else to

> I concur that the TCP is damn hard. It's just that you can't expect that "everybody else" is perfect. There is no evidence that he expected everyone else to be perfect. This is simply a debugging story about a case where he found an unexpected problem with an interesting cause. You don't need to make it an opportunity for treating him like he was stupid for having a bug. edit: and in fact, you say in your response, "You wouldn't believe how much software of the biggest industry players failed to work under that circumstances." In other words: "You wouldn't believe X! But if you're surprised by X, I will scoff and act like you're a clueless noob for not anticipating X."

acqq 12y ago
The people who expect that "everything must work because of the RFCxxx" are of course those who wouldn't believe. It's addressed to them. Regarding "There is no evidence that he expected everyone else to be perfect," he wants to use his custom TCP stack and he explains that for this case he can't do "heuristics" in order to keep the "Our TCP implementation" (which) "has a variable base SYN retransmit timout, and in this case it was roughly 500ms. So most of the time the page load would fail with our TCP stack, but succeed with an off the shelf one that had a SYN retransmit timeout of 1 second." So everything revolves really around the less common timeout times all the time, the wish to use them everywhere, the discovery that they don't work everywhere and the resulting feeling "from my point of view this is a particularly annoying bug." Which is exactly what I commented to from the start. True, the sentences in the original aren't dominating the whole text, so the less attentive reader (or readers in this case) can miss that. There are two different approaches to write the article: 1) I will show you that the other side is wrong (spending 95% of time on that). It is annoying because our clever new code doesn't work with it whereas old less clever does. 2) We developed a clever new TCP code. We thought we're clever. But some nodes on the internet are less clever. I'll show you an example. I claim that the approach 1) implies your belief that it's more important to you is that you're "right" than what actually works.
- jsnell 12y ago
  I really don't understand where you're coming from. But the post did not "spend 95% of the time showing the other side is wrong", and it's really rich to say that at the same time as you're saying that it's seasy for readers to miss the damning sentences when they're not "dominating the whole text". Most of the post was discussing the age old problem of TCP implementations needing to be bug-compatible with each other. In addition it showed a new (to me) example of this phenomenon, and did a detour into explaining why that bug was easier to trigger with our stack than some others. It's like tou've for some reason decided that I don't understand that there are broken implementations around, that it came as a complete surprise to me, and that the only thing that matters is that I'm right and the other guy is wrong. But the whole point of the post was exactly that it doesn't matter if you're right or not. If you want a production quality TCP implementation you need to support what's out there, not what's in the spec.
  - acqq 12y ago
    I fully agree with your last two sentences. Please tell, how did you at the end support what's there, I wasn't able to see that in the article?
    - jsnell 12y ago
      The short term solution was a configuration change to force a 1s SYN retransmit timeout, even if that's a 99.9th percentile handshake RTT in this environment. In the longer term we need to evaluate the timeouts in the most widely deployed systems, so that we can offer a calibrated set of completely safe / reasonable / aggressive values. For example one of the links in the post suggests that OS X has a 700ms SYN retransmit timeout. If that's true (haven't tested yet), and the same is true for iOS, then a 700ms timeout might be a pretty reasonable setting rather than an aggressive one. Because if a piece of kit fails for iOS traffic, it's not going to remain in service for long ;-) One of those cases where you can't do much more than follow the herd.
      - acqq 12y ago
        I'm glad to learn that your first solution matched exactly what I assumed it would be. Had the solution been present in the article, I certainly wouldn't comment that it's just "look how others on the internet are wrong." Thank you for sharing these new details. Together with them I have much better feeling for getting involved in reading it and discussing it. In my view the approach to solution as you stated now matches with the concepts I've stood for in my comments here. I wish you luck in your endeavours.

acqq 12y ago

The people who expect that "everything must work because of the RFCxxx" are of course those who wouldn't believe. It's addressed to them. Regarding "There is no evidence that he expected everyone else to be perfect," he wants to use his custom TCP stack and he explains that for this case he can't do "heuristics" in order to keep the "Our TCP implementation" (which) "has a variable base SYN retransmit timout, and in this case it was roughly 500ms. So most of the time the page load would fail with our TCP stack, but succeed with an off the shelf one that had a SYN retransmit timeout of 1 second." So everything revolves really around the less common timeout times all the time, the wish to use them everywhere, the discovery that they don't work everywhere and the resulting feeling "from my point of view this is a particularly annoying bug." Which is exactly what I commented to from the start. True, the sentences in the original aren't dominating the whole text, so the less attentive reader (or readers in this case) can miss that. There are two different approaches to write the article: 1) I will show you that the other side is wrong (spending 95% of time on that). It is annoying because our clever new code doesn't work with it whereas old less clever does. 2) We developed a clever new TCP code. We thought we're clever. But some nodes on the internet are less clever. I'll show you an example. I claim that the approach 1) implies your belief that it's more important to you is that you're "right" than what actually works.

jsnell 12y ago
I really don't understand where you're coming from. But the post did not "spend 95% of the time showing the other side is wrong", and it's really rich to say that at the same time as you're saying that it's seasy for readers to miss the damning sentences when they're not "dominating the whole text". Most of the post was discussing the age old problem of TCP implementations needing to be bug-compatible with each other. In addition it showed a new (to me) example of this phenomenon, and did a detour into explaining why that bug was easier to trigger with our stack than some others. It's like tou've for some reason decided that I don't understand that there are broken implementations around, that it came as a complete surprise to me, and that the only thing that matters is that I'm right and the other guy is wrong. But the whole point of the post was exactly that it doesn't matter if you're right or not. If you want a production quality TCP implementation you need to support what's out there, not what's in the spec.
- acqq 12y ago
  I fully agree with your last two sentences. Please tell, how did you at the end support what's there, I wasn't able to see that in the article?
  - jsnell 12y ago
    The short term solution was a configuration change to force a 1s SYN retransmit timeout, even if that's a 99.9th percentile handshake RTT in this environment. In the longer term we need to evaluate the timeouts in the most widely deployed systems, so that we can offer a calibrated set of completely safe / reasonable / aggressive values. For example one of the links in the post suggests that OS X has a 700ms SYN retransmit timeout. If that's true (haven't tested yet), and the same is true for iOS, then a 700ms timeout might be a pretty reasonable setting rather than an aggressive one. Because if a piece of kit fails for iOS traffic, it's not going to remain in service for long ;-) One of those cases where you can't do much more than follow the herd.
    - acqq 12y ago
      I'm glad to learn that your first solution matched exactly what I assumed it would be. Had the solution been present in the article, I certainly wouldn't comment that it's just "look how others on the internet are wrong." Thank you for sharing these new details. Together with them I have much better feeling for getting involved in reading it and discussing it. In my view the approach to solution as you stated now matches with the concepts I've stood for in my comments here. I wish you luck in your endeavours.