21 ms·

I don't see how any of this is true. The problem with SCTP is that middleboxes don't understand it and tend to drop it. This create an unfortunate situation whe

I don't see how any of this is true. The problem with SCTP is that middleboxes don't understand it and tend to drop it. This create an unfortunate situation where middleboxes refuse to support it because no-one uses it and no-one uses it because middleboxes refuse to support it. You can't just create a standard that says everyone should support SCTP and make everyone do it - standards already say that middleboxes should support it and they don't. Its bizarre that you picked WebSockets, WebRTC, and QUIC as examples of how no one supports the standardization process. WebSockets were standardized via RFC 6455 in 2011, WebRTC via W3C, work with starting in ~2011, and QUIC implemented in 2012, with IETF standardization currently underway. These are all 6+ year investments by their sponsors.

wtallis 8y ago
The sane development path would have been to build QUIC as a thin layer on top of SCTP, with a fallback to UDP implemented only if it proved necessary. I don't think the middlebox problem is a showstopper for a limited-audience experimental protocol like QUIC, and a successful QUIC-over-SCTP experiment could have gotten rid of the middlebox worries (by either motivating people to get rid of the broken middleboxes, or by proving they weren't common enough to care about), in much the same way that Apple's limited deployment of ECN has eliminated the worries about middleboxes that kill ECN flows. As for WebSockets, WebRTC, and WebAssembly, the fact that they've been standardized within their insular niche says nothing about the extent to which they duplicate functionality that has long existed outside the browser as part of the host OS or as libraries that use the low-level networking constructs that any native application has access to (but JavaScript didn't).
- petters 8y ago
  > limited-audience experimental protocol like QUIC That is not true. QUIC is currently used by a large portion of all traffic on the internet. How? Precisely because it uses UDP, which is supported everywhere (and that Google controls both Chrome and YouTube).
  - wtallis 8y ago
    Going from Google's servers to home and cellular users is a limited audience in this context, because it avoids all the legacy middleboxes that tend to plague corporate networks. It's the same effect that's responsible for IPv6 traffic being higher on weekends. Consumers may not be competent at upgrading or administering their network equipment, but at least they throw it away every few years and buy something newer (or their ISP swaps out the rental modem+router box).
    - dagenix 8y ago
      People use Chrome at work too.
    - petters 8y ago
      Traffic from people's homes and cell phones to Google really isn't a limited audience.
      - wtallis 8y ago
        I explained the sense in which it is limited compared to the entire Internet. Do you have any specific refutation of my explanation, or are you just rejecting the general idea that anything involving Google could be regarded as not all-encompassingly huge?
- dagenix 8y ago
  The "sane" thing to do is to complicate the protocol by building it on top of both SCTP _and_ UDP? How is it the "sane" thing to do to make the protocol more complicated with a fallback that easily allows the middleboxes to just ignore the SCTP option knowing that UDP will work? That wouldn't have accomplished anything, except re-affirming that middleboxes tend to reject SCTP at rates that make it unrealistic to adopt it at scale. What they did accomplish, however, is getting an open protocol to the IETF for adoption that works on the actual internet. I fail to see how that is some sort of conspiracy or incompetence. And that isn't even taking into account that building on top of SCTP would have made some of QUIC's goals hard / impossible such as eliminating the penalty for establishing encrypted connections - something which benefits the internet at large. What open protocols / standards duplicate WebSockets, WebRTC, or WebAssembly? TCP is kinda like WebSockets - but, giving any random JavaScript the ability to open TCP connections is a bad idea - nevermind that WebSockets provides are variety of useful abstractions such as messages. I'm not sure what you are saying duplicates WebRTC - there are a bunch of proprietary protocols, I guess, but, I'm not aware of anything open that its competing with. As for WebAssembly, it explicitly works with JavaScript providing significant efficiencies for certain types of code. Google, Microsoft, etc have their faults. But, picking out instances of when they have worked together, in the open, to create free, open standards that benefit everyone to complain about is just super bizarre.
  - wtallis 8y ago
    > What open protocols / standards duplicate WebSockets, WebRTC, or WebAssembly? Those aren't duplicating open protocols, they're just re-inventing the operating system inside the web browser, but with more overhead and fewer features and generally not even working as well as Java. The Web-* standards just make it possible to do things inside the browser that are already possible outside the browser, and are a bad idea to do inside the browser. Their only advantage is that it makes it a bit easier for the developer to deliver the "application", but it usually also results in the developer leaving out a lot of functionality and refinement that a native application would have.
    - dagenix 8y ago
      WebRTC isn't even working as well as Java? I guess thats hard to argue with because it makes no sense.
xorcist 8y ago
The "oh but middleboxes" argument is a universal one for bodging protocol development. For every new bit sent on the wire there will be some boxes somewhere messing it up. But there is also the opposite effect, maldesigned devices will never be replaced until users can't reach their services, in which case replacement is swift and decisive. When the big content providers require it, infrastructure improves. Just look at TLS 1.3 for a recent example. When Chrome suddenly couldn't hand shake with a major load balancing vendor, blame was placed with the latter and the problem was fixed.
- tialaramex 8y ago
  You invoke TLS 1.3 as your example, but the TLS WG spent over a _year_ on essentially nothing except finding a way to bodge the protocol so that it could get past middleboxes. Note that draft 22 in particular is focused on disguising TLS 1.3 connections as something middleboxes are least likely to meddle with. The middlebox firmwares from this year including from prominent vendors like Symantec and often misdescribed as "implementing TLS 1.3" actually mostly do what they _should_ have been doing from the outset if they were correctly implemented, which is to say they refuse to negotiate TLS 1.3 and end up proxying TLS 1.2 instead. "Oh but middleboxes" is exactly why we have TLS 1.3 and QUIC. You are correct that every bit is a new opportunity for middlebox vendors to mess it up, and that's why every possible bit is encrypted. Consider certificate compression. A certificate is about a kilobyte sent on every new connection that has large boring repetitive structures inside it (as well as many bits of random key data that won't compress), so we should clearly compress it. But there was no point even trying in TLS 1.2 and below because the cert was cleartext, and so middleboxes would try to parse it, if you compressed it they'd get confused and close the connection, or worse. Only in TLS 1.3 where certificates are encrypted, and so middleboxes can't inspect them, are we finally able to offer compression.
  - xorcist 8y ago
    TLS 1.3 could have chosen to do without certificate encryption and it would have been easier to implement. I did not mean to trivialize the enormous work to make it work with deployed hardware, but in the struggle ibetween new features and compatibilty with broken implementations, TLS ended up overwhelmingly on moving forward and breaking things and the Internet didn't collapse because of it.
0xbadcafebee 8y ago
In 1980, Ethernet was expensive, slow, buggy, difficult, and incompatible with other dominant technologies. Six years after it was created, nobody wanted to use it. How did Ethernet become a popular standard? Persistence. The guy who created Ethernet, Robert Metcalfe, hounded big corporations to use it. He left Xerox and created his own company, 3Com, just to popularize it. He got three big players at the time (DEC, Intel, Xerox) to push for it and develop the standard. Slowly they developed and improved on the standard and adapted it to be more attractive in the marketplace. Once IBM committed to pushing Ethernet, everyone knew that it was going to be mandatory for big business. By the end of the 1980's, Ethernet had won. So yeah, people aren't going to adopt your technology just because you think it's better. You have to work hard over decades to earn the adoption. Or, do what certain companies do today, and shove it into existing applications where nobody has to be convinced to adopt it. The standards process always takes time. But these "web standards" didn't even need to be standards when the people using them controlled the application platform. They just shove some new technology into their app and use it, or hide it under some other protocol, and wait for other people to start using it. ActiveX is proof that that works just fine. They developed these "web standards" because they wanted to get crap out the door immediately and get it adopted as widely as possible, as quickly as possible. And they don't invest any time or money that doesn't directly benefit their bottom line. They did it in a "web" way because they're "web" companies.
- dagenix 8y ago
  All of the technologies in question have literally either been through years long standardization or are years into standardization with major standards bodys.
  - deleted 8y ago
    [deleted]
  - peterwwillis 8y ago
    Oh, I see your confusion now: > Its bizarre that you picked WebSockets, WebRTC, and QUIC as examples of how no one supports the standardization process. I never asserted that. What I asserted was that they don't wait to standardize things to start implementing them, and that they take shortcuts in their design to speed up adoption.

wtallis 8y ago

The sane development path would have been to build QUIC as a thin layer on top of SCTP, with a fallback to UDP implemented only if it proved necessary. I don't think the middlebox problem is a showstopper for a limited-audience experimental protocol like QUIC, and a successful QUIC-over-SCTP experiment could have gotten rid of the middlebox worries (by either motivating people to get rid of the broken middleboxes, or by proving they weren't common enough to care about), in much the same way that Apple's limited deployment of ECN has eliminated the worries about middleboxes that kill ECN flows. As for WebSockets, WebRTC, and WebAssembly, the fact that they've been standardized within their insular niche says nothing about the extent to which they duplicate functionality that has long existed outside the browser as part of the host OS or as libraries that use the low-level networking constructs that any native application has access to (but JavaScript didn't).

petters 8y ago
> limited-audience experimental protocol like QUIC That is not true. QUIC is currently used by a large portion of all traffic on the internet. How? Precisely because it uses UDP, which is supported everywhere (and that Google controls both Chrome and YouTube).
- wtallis 8y ago
  Going from Google's servers to home and cellular users is a limited audience in this context, because it avoids all the legacy middleboxes that tend to plague corporate networks. It's the same effect that's responsible for IPv6 traffic being higher on weekends. Consumers may not be competent at upgrading or administering their network equipment, but at least they throw it away every few years and buy something newer (or their ISP swaps out the rental modem+router box).
  - dagenix 8y ago
    People use Chrome at work too.
  - petters 8y ago
    Traffic from people's homes and cell phones to Google really isn't a limited audience.
    - wtallis 8y ago
      I explained the sense in which it is limited compared to the entire Internet. Do you have any specific refutation of my explanation, or are you just rejecting the general idea that anything involving Google could be regarded as not all-encompassingly huge?
dagenix 8y ago
The "sane" thing to do is to complicate the protocol by building it on top of both SCTP _and_ UDP? How is it the "sane" thing to do to make the protocol more complicated with a fallback that easily allows the middleboxes to just ignore the SCTP option knowing that UDP will work? That wouldn't have accomplished anything, except re-affirming that middleboxes tend to reject SCTP at rates that make it unrealistic to adopt it at scale. What they did accomplish, however, is getting an open protocol to the IETF for adoption that works on the actual internet. I fail to see how that is some sort of conspiracy or incompetence. And that isn't even taking into account that building on top of SCTP would have made some of QUIC's goals hard / impossible such as eliminating the penalty for establishing encrypted connections - something which benefits the internet at large. What open protocols / standards duplicate WebSockets, WebRTC, or WebAssembly? TCP is kinda like WebSockets - but, giving any random JavaScript the ability to open TCP connections is a bad idea - nevermind that WebSockets provides are variety of useful abstractions such as messages. I'm not sure what you are saying duplicates WebRTC - there are a bunch of proprietary protocols, I guess, but, I'm not aware of anything open that its competing with. As for WebAssembly, it explicitly works with JavaScript providing significant efficiencies for certain types of code. Google, Microsoft, etc have their faults. But, picking out instances of when they have worked together, in the open, to create free, open standards that benefit everyone to complain about is just super bizarre.
- wtallis 8y ago
  > What open protocols / standards duplicate WebSockets, WebRTC, or WebAssembly? Those aren't duplicating open protocols, they're just re-inventing the operating system inside the web browser, but with more overhead and fewer features and generally not even working as well as Java. The Web-* standards just make it possible to do things inside the browser that are already possible outside the browser, and are a bad idea to do inside the browser. Their only advantage is that it makes it a bit easier for the developer to deliver the "application", but it usually also results in the developer leaving out a lot of functionality and refinement that a native application would have.
  - dagenix 8y ago
    WebRTC isn't even working as well as Java? I guess thats hard to argue with because it makes no sense.

xorcist 8y ago

The "oh but middleboxes" argument is a universal one for bodging protocol development. For every new bit sent on the wire there will be some boxes somewhere messing it up. But there is also the opposite effect, maldesigned devices will never be replaced until users can't reach their services, in which case replacement is swift and decisive. When the big content providers require it, infrastructure improves. Just look at TLS 1.3 for a recent example. When Chrome suddenly couldn't hand shake with a major load balancing vendor, blame was placed with the latter and the problem was fixed.

tialaramex 8y ago
You invoke TLS 1.3 as your example, but the TLS WG spent over a _year_ on essentially nothing except finding a way to bodge the protocol so that it could get past middleboxes. Note that draft 22 in particular is focused on disguising TLS 1.3 connections as something middleboxes are least likely to meddle with. The middlebox firmwares from this year including from prominent vendors like Symantec and often misdescribed as "implementing TLS 1.3" actually mostly do what they _should_ have been doing from the outset if they were correctly implemented, which is to say they refuse to negotiate TLS 1.3 and end up proxying TLS 1.2 instead. "Oh but middleboxes" is exactly why we have TLS 1.3 and QUIC. You are correct that every bit is a new opportunity for middlebox vendors to mess it up, and that's why every possible bit is encrypted. Consider certificate compression. A certificate is about a kilobyte sent on every new connection that has large boring repetitive structures inside it (as well as many bits of random key data that won't compress), so we should clearly compress it. But there was no point even trying in TLS 1.2 and below because the cert was cleartext, and so middleboxes would try to parse it, if you compressed it they'd get confused and close the connection, or worse. Only in TLS 1.3 where certificates are encrypted, and so middleboxes can't inspect them, are we finally able to offer compression.
- xorcist 8y ago
  TLS 1.3 could have chosen to do without certificate encryption and it would have been easier to implement. I did not mean to trivialize the enormous work to make it work with deployed hardware, but in the struggle ibetween new features and compatibilty with broken implementations, TLS ended up overwhelmingly on moving forward and breaking things and the Internet didn't collapse because of it.

0xbadcafebee 8y ago

In 1980, Ethernet was expensive, slow, buggy, difficult, and incompatible with other dominant technologies. Six years after it was created, nobody wanted to use it. How did Ethernet become a popular standard? Persistence. The guy who created Ethernet, Robert Metcalfe, hounded big corporations to use it. He left Xerox and created his own company, 3Com, just to popularize it. He got three big players at the time (DEC, Intel, Xerox) to push for it and develop the standard. Slowly they developed and improved on the standard and adapted it to be more attractive in the marketplace. Once IBM committed to pushing Ethernet, everyone knew that it was going to be mandatory for big business. By the end of the 1980's, Ethernet had won. So yeah, people aren't going to adopt your technology just because you think it's better. You have to work hard over decades to earn the adoption. Or, do what certain companies do today, and shove it into existing applications where nobody has to be convinced to adopt it. The standards process always takes time. But these "web standards" didn't even need to be standards when the people using them controlled the application platform. They just shove some new technology into their app and use it, or hide it under some other protocol, and wait for other people to start using it. ActiveX is proof that that works just fine. They developed these "web standards" because they wanted to get crap out the door immediately and get it adopted as widely as possible, as quickly as possible. And they don't invest any time or money that doesn't directly benefit their bottom line. They did it in a "web" way because they're "web" companies.

dagenix 8y ago
All of the technologies in question have literally either been through years long standardization or are years into standardization with major standards bodys.
- deleted 8y ago
  [deleted]
- peterwwillis 8y ago
  Oh, I see your confusion now: > Its bizarre that you picked WebSockets, WebRTC, and QUIC as examples of how no one supports the standardization process. I never asserted that. What I asserted was that they don't wait to standardize things to start implementing them, and that they take shortcuts in their design to speed up adoption.