6 ms·

I find it difficult to believe that the team that built the prototype for http/2 (SPDY), implemented it for chrome, tested it on gazillions of customers around

I find it difficult to believe that the team that built the prototype for http/2 (SPDY), implemented it for chrome, tested it on gazillions of customers around the world, wasn't bothered to talk to anyone who did networking. Sure you can argue that the tradeoffs they selected were the wrong tradeoffs and that they may have been biased by their narrow domain specific goals (reducing latency to render an average web page). Perhaps they thought that people with really horrible packet loss will just fallback to http or use amp or whatever. But I cannot believe that the mistakes were caused by them just not being aware of how networks work or, worse, failing to talk with somebody that did

liveoneggs 3y ago
Seeing early QUIC development not account for the DDoS potential of choosing UDP makes it pretty clear that networking is not top-of-mind.
- srj 3y ago
  Are you saying there's ddos potential because UDP itself doesn't have a connection handshake? There's still one on top of UDP. The initial packet could be forged, but so could one from TCP (a SYN flood).
  - pi-e-sigma 3y ago
    SYN flood cookies are probably older than me at this point
pi-e-sigma 3y ago
[flagged]
- WhitneyLand 3y ago
  It’s not an error in thinking to assume a good faith basis for someone’s efforts until there’s some reason to think otherwise. You can choose to start out with skepticism or cynicism if you like but there’s no defect in people who don’t.
  - MrBuddyCasino 3y ago
    People react to incentives. Windows got PowerShell instead of an improved cmd.exe because improving or fixing existing things does not matter in the yearly promotion package talks, but new stuff does.
    - jsnell 3y ago
      That's actually a hilarious example (in the "hilariously wrong" sense), because Jeffrey Snover had to accept a demotion to make PowerShell. He was told it was a useless project, not fit for someone at his level to work on, and bumped down a level when he persisted.
      - pi-e-sigma 3y ago
        But then he got a promotion. So it was a calculated bet that paid off.
      - MrBuddyCasino 3y ago
        Interesting, because a Windows kernel hacker told it differently [0]: These junior developers also have a tendency to make improvements to the system by implementing brand-new features instead of improving old ones. Look at recent Microsoft releases: we don't fix old features, but accrete new ones. New features help much more at review time than improvements to old ones. (That's literally the explanation for PowerShell. Many of us wanted to improve cmd.exe, but couldn't.) [0] https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-we-are-slower-than-other-oper/ https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-...
        jsnell 3y ago
        Here's a source for my claim: https://news.ycombinator.com/item?id=31302174 https://news.ycombinator.com/item?id=31302174 (I'd heard the story in person from Snover years before that, so it definitely wasn't just sour grapes from somebody about to leave the company.) I can totally believe that MS had a culture where making improvements to cmd.exe was impossible to justify, but that doesn't actually mean that a greenfield project in the same space would be considered promo-worthy either. It seems more likely that everything in that space was viewed as career suicide and you needed to be working on Internet stuff, just like at today's bigco anything except AI will have the same problem.
- foofie 3y ago
  > Your error in thinking is that you assume that they really wanted to build something better instead of building something new that would propel their careers. How do you explain that some HTTP/2 server implementations handle an order of magnitude more connections than their HTTP/1.1 implementations? Is this something you downplay as accidental benefits of doing something to propel their career? https://http2benchmark.org/ https://http2benchmark.org/ You should talk less about conspiratorial accusations you are making up on the spot and more about hard data.
KaiserPro 3y ago
> But I cannot believe that the mistakes were caused by them just not being aware of how networks work or, worse, failing to talk with somebody that did As someone who was part of the rollout of HTTP2 for a $large_website, I can confirm that "this will harm mobile performance" was outright and flatly rejected. This included people who were our reps on the w3c. I just had to sit there and wait for the real world metrics to come in "multiplexing will remove bottlenecks!" "benchmarks prove that its faster!" "you just don't understand how TCP works" "the people at google are very smart, what do you know?" "server push will reduce latency" etc etc etc. We even had the graphs of page size over time (going ever up) and average usable bandwidth (not keeping up, especially on mobile) None of that mattered until the rollout had a real world effect on our performance.
- azinman2 3y ago
  So what was that real world effect?
  - KaiserPro 3y ago
    5-25% increase in loadtime (median), which caused a drop off in ongoing activity. Users also complained.
    - pi-e-sigma 3y ago
      It doesn't matter. You can provide the numbers when asked by the proponents of HTTP2/3 'do you have proof of your claim??', they will just turn around and say your real world data is not valid or that they need peer-reviewed article in Science.
      - foofie 3y ago
        > (...) they will just turn around and say your real world data is not valid or that they need peer-reviewed article in Science. This sounds like a bullshit conspiratorial excuse. If you have real world data and you aren't afraid of having peers looking through it, nothing prevents you from presenting it to peers. So where is that data? Instead, you just have vague unsupported unbelievable claims made by random people in the internet, as if that's any way to decide over policy, and any faint doubt raised over that claim is faced with conspiratorial remarks complemented by statements on how everyone around OP is incompetent except him. I will go as far as to claim OP's assertion is unbelievable, to the point of sounding like bullshit. It's entirely unbelievable that people designing protocols for a multinational corporation whose bread and butter is stuff done over TCP connections were oblivious to how TCP works, and the most incompetent of them would bother to design the first major revision of HTTP. Unbelievable. But hey, some random guy online said something, so it must be true!
bsdetector 3y ago
SPDY's header compression allowed cookies to be easily leaked. This vulnerability was well known at the time so had they even asked an intern at Google Zero to look at it they would have been immediately schooled. https://bugzilla.mozilla.org/show_bug.cgi?id=779413 https://bugzilla.mozilla.org/show_bug.cgi?id=779413 In their performance tests vs HTTP 1.1 the team simulated loading many top websites, but presumably by accident used a single TCP connection for SPDY across the entire test suite (this was visible in their screenshots of Chrome's network panel, no connection time for SPDY). They also never tested SPDY against pipelining - but Microsoft did and found pipelining performed the same. SPDY's benefit was merely a cleaner, less messy equivalent of pipelining. So I think it's fair to say these developers were not the best Google had to offer.
- pi-e-sigma 3y ago
  another explanation - they did test it in other scenarios but the results were against their hopes so they 'accidentally' omitted such tests in the 'official' test suite. Very common tactic, you massage your data until you get what you want.

liveoneggs 3y ago

Seeing early QUIC development not account for the DDoS potential of choosing UDP makes it pretty clear that networking is not top-of-mind.

srj 3y ago
Are you saying there's ddos potential because UDP itself doesn't have a connection handshake? There's still one on top of UDP. The initial packet could be forged, but so could one from TCP (a SYN flood).
- pi-e-sigma 3y ago
  SYN flood cookies are probably older than me at this point

pi-e-sigma 3y ago

[flagged]

WhitneyLand 3y ago
It’s not an error in thinking to assume a good faith basis for someone’s efforts until there’s some reason to think otherwise. You can choose to start out with skepticism or cynicism if you like but there’s no defect in people who don’t.
- MrBuddyCasino 3y ago
  People react to incentives. Windows got PowerShell instead of an improved cmd.exe because improving or fixing existing things does not matter in the yearly promotion package talks, but new stuff does.
  - jsnell 3y ago
    That's actually a hilarious example (in the "hilariously wrong" sense), because Jeffrey Snover had to accept a demotion to make PowerShell. He was told it was a useless project, not fit for someone at his level to work on, and bumped down a level when he persisted.
    - pi-e-sigma 3y ago
      But then he got a promotion. So it was a calculated bet that paid off.
    - MrBuddyCasino 3y ago
      Interesting, because a Windows kernel hacker told it differently [0]: These junior developers also have a tendency to make improvements to the system by implementing brand-new features instead of improving old ones. Look at recent Microsoft releases: we don't fix old features, but accrete new ones. New features help much more at review time than improvements to old ones. (That's literally the explanation for PowerShell. Many of us wanted to improve cmd.exe, but couldn't.) [0] https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-we-are-slower-than-other-oper/ https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-...
      - jsnell 3y ago
        Here's a source for my claim: https://news.ycombinator.com/item?id=31302174 https://news.ycombinator.com/item?id=31302174 (I'd heard the story in person from Snover years before that, so it definitely wasn't just sour grapes from somebody about to leave the company.) I can totally believe that MS had a culture where making improvements to cmd.exe was impossible to justify, but that doesn't actually mean that a greenfield project in the same space would be considered promo-worthy either. It seems more likely that everything in that space was viewed as career suicide and you needed to be working on Internet stuff, just like at today's bigco anything except AI will have the same problem.
foofie 3y ago
> Your error in thinking is that you assume that they really wanted to build something better instead of building something new that would propel their careers. How do you explain that some HTTP/2 server implementations handle an order of magnitude more connections than their HTTP/1.1 implementations? Is this something you downplay as accidental benefits of doing something to propel their career? https://http2benchmark.org/ https://http2benchmark.org/ You should talk less about conspiratorial accusations you are making up on the spot and more about hard data.

KaiserPro 3y ago

> But I cannot believe that the mistakes were caused by them just not being aware of how networks work or, worse, failing to talk with somebody that did As someone who was part of the rollout of HTTP2 for a $large_website, I can confirm that "this will harm mobile performance" was outright and flatly rejected. This included people who were our reps on the w3c. I just had to sit there and wait for the real world metrics to come in "multiplexing will remove bottlenecks!" "benchmarks prove that its faster!" "you just don't understand how TCP works" "the people at google are very smart, what do you know?" "server push will reduce latency" etc etc etc. We even had the graphs of page size over time (going ever up) and average usable bandwidth (not keeping up, especially on mobile) None of that mattered until the rollout had a real world effect on our performance.

azinman2 3y ago
So what was that real world effect?
- KaiserPro 3y ago
  5-25% increase in loadtime (median), which caused a drop off in ongoing activity. Users also complained.
  - pi-e-sigma 3y ago
    It doesn't matter. You can provide the numbers when asked by the proponents of HTTP2/3 'do you have proof of your claim??', they will just turn around and say your real world data is not valid or that they need peer-reviewed article in Science.
    - foofie 3y ago
      > (...) they will just turn around and say your real world data is not valid or that they need peer-reviewed article in Science. This sounds like a bullshit conspiratorial excuse. If you have real world data and you aren't afraid of having peers looking through it, nothing prevents you from presenting it to peers. So where is that data? Instead, you just have vague unsupported unbelievable claims made by random people in the internet, as if that's any way to decide over policy, and any faint doubt raised over that claim is faced with conspiratorial remarks complemented by statements on how everyone around OP is incompetent except him. I will go as far as to claim OP's assertion is unbelievable, to the point of sounding like bullshit. It's entirely unbelievable that people designing protocols for a multinational corporation whose bread and butter is stuff done over TCP connections were oblivious to how TCP works, and the most incompetent of them would bother to design the first major revision of HTTP. Unbelievable. But hey, some random guy online said something, so it must be true!

bsdetector 3y ago

SPDY's header compression allowed cookies to be easily leaked. This vulnerability was well known at the time so had they even asked an intern at Google Zero to look at it they would have been immediately schooled. https://bugzilla.mozilla.org/show_bug.cgi?id=779413 https://bugzilla.mozilla.org/show_bug.cgi?id=779413 In their performance tests vs HTTP 1.1 the team simulated loading many top websites, but presumably by accident used a single TCP connection for SPDY across the entire test suite (this was visible in their screenshots of Chrome's network panel, no connection time for SPDY). They also never tested SPDY against pipelining - but Microsoft did and found pipelining performed the same. SPDY's benefit was merely a cleaner, less messy equivalent of pipelining. So I think it's fair to say these developers were not the best Google had to offer.

pi-e-sigma 3y ago
another explanation - they did test it in other scenarios but the results were against their hopes so they 'accidentally' omitted such tests in the 'official' test suite. Very common tactic, you massage your data until you get what you want.