7 ms·

The Need for Web UDP

100 points by mrmoka 9y ago

api 9y ago
Just tweeted this and plan to publicize. If we had web UDP we could port ZeroTier pretty easily to run in the browser, allowing web apps to coexist with machines on true virtual networks. It'd probably be lighter weight than WebRTC, which is IMHO an over-engineered nightmare. I'd like to see just the A/V encode/decode parts of WebRTC live on and the rest of it get deprecated in favor of web UDP and open-ended browser based P2P implementations. That's what should have happened, not a monolithic katamari ball of a standard.
- xg15 9y ago
  I think there is some value in having a (relatively) small number of transport-level protocols with known semantics. If every web page would effectively reinvent their own transport-level protocol* including subtly different connection handling, congestion behavior and drop/reorder tolerance, that sounds like it would make life a nightmare for all network intermediaries. (* I know the transport-level protocol is technically UDP but that doesn't count because all he practically relevant aspects are defined on top of it) Also, ICE etc solves a real problem - that users of Web UDP would have to deal with as well. Why demand that everyone reinvents the solution for themselves if we can include a standard solution in the browsers for everyone?
- mintplant 9y ago
  Any insight as to why this comment has been so heavily downvoted? I don't see anything that would justify it.
  - jandrese 9y ago
    I don't know about other people, but it smells a bit to me like "this standard is too complicated, how hard can it be?", and then people implement their own thing and end up reinventing pretty much the entire standard, only in a nonstandard way.
- kelnos 9y ago
  I don't consider WebRTC over-engineered at all. It's not a trivial protocol, sure. But doing p2p sessions over today's Internet isn't trivial. Yes, if you just consider a client-server model where the server has a public, routable, non-firewalled IP, then you can do away with ICE/STUN/TURN, and it gets simpler. But that's not what WebRTC was designed for. The SDP stuff might seem a bit arcane, and I would agree with you, but it's a widely-used telephony industry standard and there are libraries that will generate/parse them for you without you needing to do much. Bona fides: I've implemented server-side WebRTC in C++ and Java. Was it trivial? No. Was it ridiculously difficult? No.
  - bewo001 9y ago
    The telephony argument for SDP was brought up a lot in the IETF. However, few SIP devices -- if any -- understand all the SDP extensions WebRTC has introduced. With RTP/RTCP the situation is even worse. You always need a gateway.
  - api 9y ago
    It doesn't have to be as complex as the ICE/STUN/TURN stack but that's not really my point. Building blocks and programmability are better for a long lived platform like the web than giant inflexible monoliths. UDP and web assembly lets you implement the stack you describe and anything else that comes down the pike.
kazinator 9y ago
Using UDP with the web on a wide scale will either replicate everything in TCP, inside UDP wrapping, or else cause big problems all over the Internet. It will be fast only in the beginning when a few clients are participating, but then screw over the infrastructure with degenerative congestive behaviors when "everyone" is on it. And by then, it will be a standard everyone is stuck with, with the only way out being to complicate it with a tirade of hacky refinements based on guesswork combined with crossed fingers. That's not even considering malicious interference: what sorts of attacks will be discovered on this new UDP based shit, and what sorts of hacks will be required to mitigate them.
- tlb 9y ago
  I know that was the conventional wisdom, from back when backbone links were the bottleneck. But in the modern internet, almost all the congestion is at the edges. Since most traffic for games is server->client, most of the congestion will happen when several users are competing for the same customer link (DSL or cable modem). This already happens with streaming services, and people just yell at each other to stop downloading updates while I'm watching Netflix.
  - kazinator 9y ago
    That could change one fine day when those edges get their stuff together. Indeed, the subscriber lines and surrounding edge hardware have not kept up with the times. Depending on where you are and who your provider is, chances are you're getting the same shitty line rates you had ten years ago (or more), though you have more memory, a bigger hard drive and a faster CPU, and the backbone is faster.
  - zlynx 9y ago
    Anywhere with a lot of Gigabit Fiber installed, the congestion is _not_ at the edges. It's further in. If all of those installed Gigabit edges simultaneously used 1 Gbps download, it wouldn't happen. They'd get much less.
- xxgreg 9y ago
  Too late... Chrome already uses HTTP over UDP. https://en.wikipedia.org/wiki/QUIC https://en.wikipedia.org/wiki/QUIC
znpy 9y ago
Just use QUIC and advocate for its adoption.
- Matthias247 9y ago
  That doesn't necessarily solve the problem which is in focus here. The QUIC version which is available in browsers (ok, Chrome only) is not only the QUIC stream layer, but also the QUIC HTTP adaption layer. From javascript side you just interact with HTTP and use QUIC under the hood. However with HTTP you also get all HTTP semantics (headers, reliability, ordering inside of request/response streams, etc.). What is requested is an additional protocol and API which avoids all the overhead and just allows to send and receive messages with best effort - because games and other realtime applications may prefer to build their own reliability mechanism on top. The only way to use HTTP/QUIC for packetlike communication might be to send each packet inside a seperate HTTP request. But I guess that will have a super high overhead (lifecycle of a whole stream must be managed for a packet which actually has no lifecycle) and will most likely also not deliever the expected results (afaik HTTP on top of QUIC still has head-of-line blocking for request/stream establishment. Request headers must be received in order). New javascript APIs which are utilizing QUIC could work. However one would need to explore if QUIC is actually helpful for target applications, since it provides a stream semantic, whereas UDP is purely packet based. QUIC might also introduce similar issues like WebRTC to the server side: It's a complex protocol spanning multiple layers (everything from flow-control to encrytion). Therefore it will be hard to integrate into environments where no QUIC library is available. But that's only a feeling, since I haven't yet reviewed the QUIC specification in detail.
justsomedood 9y ago
Wouldn't this make it pretty easy to have browser clients unknowingly participate in DoS attacks?
- dsl 9y ago
  Yes. The only way this could be done safely is if you are required to establish a TCP connection, and then "upgrade" it to UDP. There are too many pointy sticks that developers could impale themselves on, with the side effect of creating DDoS vectors.
  - deleted 9y ago
    [deleted]
  - geofft 9y ago
    Can you do it safely if you're required to make an HTTPS request to the same hostname with some standardized request (a la CORS preflight) and get an answer back saying "Yes, this origin may connect to me on these UDP ports", and then hang onto that permission indefinitely? The nice thing about having a persistent permission instead of an upgrade on each request is that a service worker that's woken up by a push notification or similar can immediately send UDP traffic instead of doing a TCP (+ HTTPS?) handshake. Since it's restricted by origin (probably using literally the same mechanism CORS uses) and over HTTPS, a malicious actor can't DDoS anyone but themselves. If you're really worried, maybe extend it to allow the server to limit the duration of the permission and the maximum bandwidth, but I think you don't need that. EDIT: Oh, oops, binding to the hostname doesn't help because you can just repoint your hostname in DNS at someone else. You'd ideally need to bind it to the IP, in which case you definitely want it to be a time-limited permission. (But I think that attack is also feasible, though a bit harder, with the handshake-before-each-UDP-connection model. Just have the attacker set up a custom DNS server for their domain, which for any hostname sends you a low-TTL response pointing to the attacker's HTTPS server, and then a higher-TTL response to the victim. Each user gets pointed at a random hostname within that domain.)
    - jandrese 9y ago
xg15 9y ago
So if the main justification of this proposal is "WebRTC is too complicated", wouldn't that more speak for a WebRTC library and/or server geared towards games?
- nitwit005 9y ago
  Yes, it seems like a server side complexity issue should be a fixable problem without updating the standards. I suppose you'll still need to deploy a stun/turn server to deal with the NAT issues unless you're happy with IPv6 only, but that's not really something the standard can fix.
- z3t4 9y ago
  Last time I checked on WebRTC tutorials and examples was either too old and deprecated, or required the latest Chrome with some flags enabled. The best we have right now for real time streaming is HLS with up to 20 seconds or more delay. We had real time video chat 20 years ago, why can't we have it in the browser today !?
  - TD-Linux 9y ago
    I think you checked too long ago. Appear.in, Jitsi, Discord, and Cisco Spark are all working with WebRTC now.
- mrmoka 9y ago
  As mentioned in the doc, one of the options is to simplify WebRTC by making some components optional to enable it's better adoption and easier to implement on the back-end as well as on front-end.
- TD-Linux 9y ago
  It sounds like you're describing HumbleNet: https://github.com/HumbleNet/HumbleNet https://github.com/HumbleNet/HumbleNet
  - mrmoka 9y ago
    And with WebUDP life for those guys would be much easier.
deleted 9y ago
[deleted]
eecc 9y ago
Can't we just rewrite the Linux kernel in JavaScript and boot it off a browser ... /s (hopefully)
- pdkl95 9y ago
  https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- nomadlogic 9y ago
  netbsd beat you to this by 5 years or so: https://blog.netbsd.org/tnf/entry/kernel_drivers_compiled_to_javascript https://blog.netbsd.org/tnf/entry/kernel_drivers_compiled_to...
- trelliscoded 9y ago
  Why, yes. Yes you can. http://jslinux.org/ http://jslinux.org/
pdkl95 9y ago
> Requirements > 1. Security - it has to benefit from SSL. There is a lot more to security than transport-layer encryption and authentication. > Connection based UDP is too hard, so re-inventing TCP? > p2p is not reliable ... monetization Oh, you want require the SAaSS[1] model. > Simple to use The already-stated "requirements" are asking for something more complex than WebRTC. > Minimum header overhead Wait, are you thinking about using UDP to transport HTTP?! Do you even know what your MTU is? > WebRTC suffers from complexity That complexity exists for reason. Nowhere in this document is a discussion of the potential problems of using UDP or the ways tthe new service might be exploited by malicious actors. [1] Service as a Software Substitute
- mrmoka 9y ago
  > There is a lot more to security than transport-layer encryption and authentication. You are welcome to PR. > Connection based This could be explored: starting from simple handshake, all the way to fully connection based protocol. Open for discussion based on developer needs. > The already-stated "requirements" are asking for something more complex than WebRTC. You are welcome to highlight specifics that makes you think that way. > Wait, are you thinking about using UDP to transport HTTP?! Do you even know what your MTU is? UDP is not streamed but message based protocol. As WebSockets implement their transport layer over pure TCP, WebUDP could implement it's own layer over pure UDP for various reasons. > > WebRTC suffers from complexity > That complexity exists for reason. For P2P type communications, this complexity is perhaps reasonable. For Server-Client type communications not at all. > Nowhere in this document is a discussion of the potential problems of using UDP or the ways tthe new service might be exploited by malicious actors. This document is initial effort to bring public discussion to form a reasonable shape of what WebUDP could look like. You are welcome to participate.
  - pdkl95 9y ago
    > UDP is not streamed but message based protocol. I'm very[1] familiar with the IP family of protocols. > Open for discussion If you don't know what your requirements are, you shouldn't be choosing a transport technology. It sounds like you want an library that wraps WebSockets or WebRTC and handles most of the complexity. > WebUDP could implement it's own [transport] layer over pure UDP Then you want TCP. The only reason to use UDP is to avoid the complexities of a transport layer. Transport reliability is very hard; this isn't something that is easy to re-implement by yourself in UDP. More importantly, I take it you don't know what your MTU is? The Maximum Transmission Unit[2] the maximum packet size. On ethernet-based networks, it's probably ~0-100 octets less than ethernet's 1500 octet MTU. You need to keep UDP packets under this limit, or they will fragment. Fragmented IP packets may not arrive at all and even when they do, the OS will wait until all fragments arrive before passing the data up to the app. If you're insane and send HTTP headers in each packet, you've wasted most of your data space. Each packet? Shouldn't we send headers in the first packet only? Except that every packet IS the "first packet" in stateless protocol like UDP. It's the transport features of TCP that create ordered-data semantics. [1] I used to write firmware for embedded systems. That included writing - from scratch, in Z80 asm - the entire network layer: ethernet (RealTek), ARP, IP, UDP, TCP, SNMP, HTTP, etc. [2] https://en.wikipedia.org/wiki/Maximum_transmission_unit https://en.wikipedia.org/wiki/Maximum_transmission_unit
soapdog 9y ago
Firefox OS had TCP[0] and UDP[1] sockets as Web APIs. They were quite pleasant to use as a developer and the only way to create a real mail client (needs TCP to implement POP, IMAP, SMTP in JS). I wish more Firefox OS APIs had become web standards. They would allow for some very powerful PWAs. [0]: https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/TPC_Socket_API https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/... [1]: https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/UDPSocket https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/...
- mrmoka 9y ago
  Those implementations were created to be utilised within FirefoxOS where applications are granted permissions by user when installing them. And access to several API would be strictly regulated by OS it self. In Web context this approach wouldn't work and would lead to security issues. Just like there was need or WebSockets (TCP), there is need for similar API for UDP but it cannot be pure access for creating UDP connections as this leads to many security concerns.
  - soapdog 9y ago
    I am a fan of the "just stick a security popup and let people choose" option but I understand that is not the same as having proper security.
- geofft 9y ago
  Chrome OS supports the same thing: https://developer.chrome.com/apps/app_network https://developer.chrome.com/apps/app_network The SSH and mosh apps use a binding between the POSIX socket interface on the Native Client side and these APIs on the JS side.
- jcranmer 9y ago
  > Firefox OS had TCP[0] and UDP[1] sockets as Web APIs. They were quite pleasant to use as a developer and the only way to create a real mail client (needs TCP to implement POP, IMAP, SMTP in JS). The biggest problem with Firefox OS's TCP standard is that it used an event-driven model, which is somewhat at odds with more current promise-based thinking. The more natural version is to use something based on WHATWG Streams, but that spec has been stuck in vaporware-land for years. > I wish more Firefox OS APIs had become web standards. They would allow for some very powerful PWAs. The TCP specification actually was undergoing standardization (reformatted to use the streams API): https://www.w3.org/TR/tcp-udp-sockets/ https://www.w3.org/TR/tcp-udp-sockets/ . The problem was the working group ended up closing down, and since the specification wasn't suitable for use on webpages, it ended up with nobody to host it.
smcdow 9y ago
Maybe you'd have more interest if you wrote up a proper RFC.
- mrmoka 9y ago
  This is collaborative effort. I act from my capabilities, but people with certain skillset are welcome to contribute with proper RFC.
shurcooL 9y ago
Are people aware of https://www.w3.org/TR/tcp-udp-sockets/ https://www.w3.org/TR/tcp-udp-sockets/? I didn't see it mentioned so far.
- mrmoka 9y ago
  This spec been there for very long time, and has been adopted by FirefoxOS (deprecated platform). Which exposes low-level access to establish pure TCP and UDP connections with permissions flow by environment. It exposes many security concerns, that's why WebSockets were more favourable over TCPSocket. We want similar for UDP.
  - LunaSea 9y ago
    Not having raw TCP means you can't speak to any existing TCP protocol through a browser. It might not be a useful feature but I think that not taking it into account is an issue because most use cases can't be implemented with WebSockets.
    - mrmoka 9y ago
      Ability to connect to raw TCP or UDP from a browser is a major security hole. Due to that, WebSockets were created were handshake is handled by browser transparently from developer ensuring port scanning is not possible. As well as to preserver origin-based security model of HTTP. Which we want for WebUDP as well.
TD-Linux 9y ago
I think you're going to need a stronger argument for "Why not WebRTC", or at least concrete proposals about what parts of the API you would change. For example, "SDP parsing is too complex, have a JS API to set up a client-server connection without a SDP". IMO the most complex parts of WebRTC are the SRTP-DTLS encryption (except you also specified TLS as a requirement for Web UDP), and STUN/TURN (which are optional and not required for client-server).
- mrmoka 9y ago
  This is valuable input, you are welcome to contribute in form of PR!
  - TD-Linux 9y ago
    Well, the problem is that I currently think WebRTC 1.0 is sufficient. For the example I gave, I think a simple JS library to write out the SDP is a perfectly fine solution. So I'm more asking, what did you find wrong with WebRTC?
    - mrmoka 9y ago
      Simply look at present state of WebRTC adoption by back-end services for use in server-client cases. Fist of all it is not designed for server-client cases. Second, after so many years, it is still not well adopted and used for server-client cases due to it's complexity on both sides - back-end implementation and front-end usage. If you compare it to speed of adoption of WebSockets, variety of WebSockets implementations and how much it is used commercially. There are many conversations by many developers who as well attempted using WebRTC for server-client communications, and it is apparent trend. One of the developers of WebRTC team at Google who worked on DataChannel and network code admits himself that their team is aware of complexity and difficulties with WebRTC in server-client cases: https://news.ycombinator.com/item?id=13266874 https://news.ycombinator.com/item?id=13266874
      - LunaSea 9y ago
Wofiel 9y ago
Anyone interested in this might find some enlightenment in Glenn Fiddler's whitepaper. [1] It talks about the issues with TCP-based connections, WebSockets, QUIC, WebRTC and provides a solution (with code) to doing UDP in browser. [1] https://gafferongames.com/post/why_cant_i_send_udp_packets_from_a_browser/ https://gafferongames.com/post/why_cant_i_send_udp_packets_f...
- gafferongames 9y ago
  Update: there is now a full browser-based implementation of netcode.io too! https://github.com/RedpointGames/netcode.io-browser https://github.com/RedpointGames/netcode.io-browser
lxtx 9y ago
Posted this recently in another thread, but maybe someone will find https://github.com/seemk/WebUdp https://github.com/seemk/WebUdp useful as there have been many WebRTC threads lately. It's a WebRTC DataChannel server implementation for out of order, unreliable UDP traffic for browsers that has built-in SDP signaling and STUN.
- mrmoka 9y ago
  Just looking at the complexity of "minimal" implementation only highlights the need for different solution.
remline 9y ago
SCTP would be the logical choice for supporting both streams and messages. No one really wants to support a network with the evil of arbitrary UDP from the browser. In SCTP, the handshake combined with crypto tricks can allows a server to make sure the initiator stores a larger cookie than it needs to hold for verification, throttling the DDOS riffraff.
- mrmoka 9y ago
  SCTP have been mentioned in the repo: https://github.com/Maksims/web-udp-public/issues/1#issuecomment-318179584 https://github.com/Maksims/web-udp-public/issues/1#issuecomm...
  - remline 9y ago
    The reasoning there is kind of lame, every filter knows how to pass SCTP or UDP and doesn't pass SCTP since it is unpopular and UDP because stopping it is most of why you are filtering. Making an SCTP web standard would improve endnode support (and actual app use) which is beginning to wane and are SCTPs adoption problems.
    - mrmoka 9y ago
      It is indeed a bit like chicken-and-egg situation here. But SCTP implements reliability and ordered delivery making it more of an alternative to TCP, than a solution for low-latency communication with cases where reliability and/or ordered delivery is not required.
      - rjsw 9y ago
        There is also DCCP [1]. [1] https://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol https://en.wikipedia.org/wiki/Datagram_Congestion_Control_Pr...
        remline 9y ago
        I'm not familiar with DCCP, but as long as browsers don't get access to DCCP-UDP encapsulation without some work by the user it seems like another alternative to use to use web security considerations as leverage to ween a critical mass off of UDP.
mnarayan01 9y ago
For this to be taken seriously, I think you need to demonstrate that you're capable of using WebRTC to do what you need. Without a decent nod in that direction, people are going to think that you're just not aware of the potential complexities.
- mrmoka 9y ago
  Worth mentioning again: this effort is to explore server-client low-latency, not peer-to-peer scenarios which WebRTC solves well. And this is collaborative effort, not personal. So all input is welcome. I've used WebRTC for p2p and server-client cases, and it is nightmare for later. And many other developers have expressed very similar experience when it comes to server-client cases. Even more, after many years we see very little adoption of WebRTC for server-client cases due to it's complexity. WebSockets on the other hand took very little time to get adopted by many back-end platforms as well as browser vendors. I wrote my own WebSockets solution long time ago on .Net before 4.5 .Net was released (includes own WebSockets implementation).
jstewartmobile 9y ago
So many of these comments are like "UDP is not TCP!" or "Muh TCP guarantees!", then they go on to mention WebRTC?!!! I mean, if you're streaming audio and video Real Time, is there really any point to TCP? If a few frames get dropped, then bursted back once the connection stabilizes, does that improve the user experience in any way? WebRTC seems like a perfect candidate for UDP communications for the actual media streams.
- mrmoka 9y ago
  WebRTC is best option for media streams today for peer-to-peer cases. The goal of the topic is to explore simple option for server-client communication using low-latency communication, without reliability and without ordered delivery. WebRTC can be used for such case, although it is not designed for it. Due to that implementation is very complex and not much adopted. This is something we trying to explore, either new API or simplifications to WebRTC to make it simple choice for UDP in server-client scenarios.
  - detaro 9y ago
    Given the kind of feedback happening (and my initial reaction admittedly was similar), maybe a different name would help with perception (I'm already not a big fan of "WebSockets", but "WebTCP" would have been worse), promoting the goals over the implementation detail of UDP?
    - mrmoka 9y ago
      If there is alternative transport protocol to enable low-latency delivery as efficient as UDP, then it is worth exploring. UDP - is something been used by many industries for long time and is well known protocol to make a foundation from.
  - jstewartmobile 9y ago
    It just seems like most real-life usages of WebRTC are either media-centric where TCP does more harm than good, or multiplayer scenarios where it's a wash since TCP's ordering is a pro while TCP's overhead is a con.
kelnos 9y ago
This seems to come up every now and then, and I see the same arguments, and they're still not compelling. WebRTC data channels in unreliable mode will work just fine. Is it as easy as opening up a WebSocket connection? No, it's not. Is it as easy on the server side as accepting a WebSocket connection? Also no. But it really isn't that hard[0], and people have built libraries to help you out. So just use one, and move on with your life. And you also benefit from a standard that has been fleshed out over multiple years by some very smart (if imperfect) people. On the browser side, it's already supported by all major browsers, with the notable exception of iOS Safari (which should change this fall with the release of iOS 11)[1]. Even though it's not ideal, you can fall back to WebSocket for the few holdouts. [0] Source: I've done it before, building it from scratch. [1] https://caniuse.com/#feat=rtcpeerconnection https://caniuse.com/#feat=rtcpeerconnection
geocar 9y ago
I've written a WebRTC "server" that can establish such a connection (and also acts as it's own STUN/TURN server) and hand off sockets to a local process. WebRTC isn't very complicated. The hardest part is probably ICE, which basically involves each point telling eachother what they see, and potentially consulting a third party (STUN/TURN). I'd love to see more magic there, but once that's in-place, I don't see what's so hard about just using DataChannels. One idea might be to put signalling into HTTP headers, e.g. have the client and server introduce something like: ICE: sdp-desc... and if so, allow WebRTC to skip the ICE negotiation step if speaking to the server.
ksec 9y ago
I read 5G is doing something similar, or rather something new to solve this problem. They are completely remaking the TCP/IP stack. Anyone knows anything about that?
- dr_hooo 9y ago
  The ETSI NGP ISG[1] is looking at next generation protocols, also in the context of 5G. "This ISG is seen as a transitional group i.e. a vehicle for the 5G community (and others of interest) to first gather their thoughts and prepare the case for the Internet community’s engagement in a complementary and synchronised modernisation effort." The efforts seems to be in an quite early stage for now (architecture, models, requirements, etc). I personally don't see TCP/IP going anywhere with 5G, but we may see more parallel deployments of protocols within isolated 5G network slices. [1] http://www.etsi.org/technologies-clusters/technologies/next-generation-protocols http://www.etsi.org/technologies-clusters/technologies/next-...
captainmuon 9y ago
This seems to propose that you can only connect to a certain server, similar to the same-origin-policy. What I would really love instead is the possibility to connect to arbitrary IPs to be able to implement real P2P. The linked posts dismiss this early because of the possibility to cause DDOS, but really, you can already do that from a hacked desktop "Quake", so there is no harm in being able to do it from a browser-based "Quake". What you'd have to prevent is drive-by use of UDP, not use of UDP period. I would propose having two HTML profiles in future, HTML document, and HTML application (and maybe HTML legacy). HTML document would be restricted in what you can do, and would be primarily for reading Hypertext. For HTML application you would have to go through a few clicks to install or activate it - now you are going to say that people will just click it away, but that is already the case with current desktop app installers, so it is not more insecure! An application profile page will be able to access the net just like any other native application. Most importantly, it will be able to bypass same-origin policy and send UDP and TCP anywhere - but not with credientials of course. You'd still have the problem of being able to probe internal networks, and being able to manipulate UPnP routers. For the first, the network admin could have a group profile setting or similar to disable this kind of access. For the second, browsers could selectively block this on a case-by-case basis if needed. For the problem of DDOS, I think we should not let that restrict us from implementing useful technologies. Rather we should fix it at the source. For example, maybe one could lock down certain routes if an attack is detected. All traffic along these routes is throttled, unless you send along a proof-of-work token. I'm just making this up, but my point is that I think we haven't exhausted all options here.
- bewo001 9y ago
  For p2p, you already have the webrtc data channel which handles all the nasty NAT traversal and DDoS issues. Its browser API should be less volatile now than it has been in the past. Implementing a WebRTC data channel endpoint in a server is not for the faint of heart, though. You would have to implement a lot of complex RfCs.
  - captainmuon 9y ago
    Yeah, but you need a central server, right? You cannot make a DHT for example, like Kademlia or trackerless Bittorrent.
deleted 9y ago
[deleted]
RajuVarghese 9y ago
One thing that I do not see mentioned here is multicast. Are there any advantages? Watching a live sports game, for instance. Since multicast is connection-less and sent only over UDP, the more distant discussion about introducing multicast into browsers never takes place. Having used a multicast video stream for many years in an enterprise setting I can unequivocally state that this would decrease network utilization. Especially in the years to come as the interwebs get clogged up with broadcast-type data.
- mrmoka 9y ago
  The main goal of this effort is to explore server-client communication scenarios.
- wbl 9y ago
  ISPs are not supporting multicast over the public internet.
  - RajuVarghese 9y ago
    They will if it becomes a standard way of broadcasting. They will save quite a bit of network load.
    - fulafel 9y ago
      The tech has been standardized as IPTV, and it sees a fair bit of use. But not over the public internet (for one, because ISPs don't support it...)
Matheus28 9y ago
I'd also like to draw some attention to this proposal: https://github.com/Maksims/web-udp-public/issues/6 https://github.com/Maksims/web-udp-public/issues/6
- gafferongames 9y ago
  This proposal lacks challenge/response and makes game server vulnerable to being used in DDoS amplification attacks if they use request/response pattern. Also, a proposal without packet encryption in 2017, seriously?!
LinuxBender 9y ago
Most home users probably allow UDP out of their network. How many businesses by default allow UDP outbound on any port? Will the documentation/RFC's encourage folks to fail gracefully if UDP is not supported in their network? Could this spec include support for SRV records? It isn't allowed in http/1.1.

100 points by mrmoka 9y ago

api 9y ago

Just tweeted this and plan to publicize. If we had web UDP we could port ZeroTier pretty easily to run in the browser, allowing web apps to coexist with machines on true virtual networks. It'd probably be lighter weight than WebRTC, which is IMHO an over-engineered nightmare. I'd like to see just the A/V encode/decode parts of WebRTC live on and the rest of it get deprecated in favor of web UDP and open-ended browser based P2P implementations. That's what should have happened, not a monolithic katamari ball of a standard.

xg15 9y ago
I think there is some value in having a (relatively) small number of transport-level protocols with known semantics. If every web page would effectively reinvent their own transport-level protocol* including subtly different connection handling, congestion behavior and drop/reorder tolerance, that sounds like it would make life a nightmare for all network intermediaries. (* I know the transport-level protocol is technically UDP but that doesn't count because all he practically relevant aspects are defined on top of it) Also, ICE etc solves a real problem - that users of Web UDP would have to deal with as well. Why demand that everyone reinvents the solution for themselves if we can include a standard solution in the browsers for everyone?
mintplant 9y ago
Any insight as to why this comment has been so heavily downvoted? I don't see anything that would justify it.
- jandrese 9y ago
  I don't know about other people, but it smells a bit to me like "this standard is too complicated, how hard can it be?", and then people implement their own thing and end up reinventing pretty much the entire standard, only in a nonstandard way.
kelnos 9y ago
I don't consider WebRTC over-engineered at all. It's not a trivial protocol, sure. But doing p2p sessions over today's Internet isn't trivial. Yes, if you just consider a client-server model where the server has a public, routable, non-firewalled IP, then you can do away with ICE/STUN/TURN, and it gets simpler. But that's not what WebRTC was designed for. The SDP stuff might seem a bit arcane, and I would agree with you, but it's a widely-used telephony industry standard and there are libraries that will generate/parse them for you without you needing to do much. Bona fides: I've implemented server-side WebRTC in C++ and Java. Was it trivial? No. Was it ridiculously difficult? No.
- bewo001 9y ago
  The telephony argument for SDP was brought up a lot in the IETF. However, few SIP devices -- if any -- understand all the SDP extensions WebRTC has introduced. With RTP/RTCP the situation is even worse. You always need a gateway.
- api 9y ago
  It doesn't have to be as complex as the ICE/STUN/TURN stack but that's not really my point. Building blocks and programmability are better for a long lived platform like the web than giant inflexible monoliths. UDP and web assembly lets you implement the stack you describe and anything else that comes down the pike.

kazinator 9y ago

Using UDP with the web on a wide scale will either replicate everything in TCP, inside UDP wrapping, or else cause big problems all over the Internet. It will be fast only in the beginning when a few clients are participating, but then screw over the infrastructure with degenerative congestive behaviors when "everyone" is on it. And by then, it will be a standard everyone is stuck with, with the only way out being to complicate it with a tirade of hacky refinements based on guesswork combined with crossed fingers. That's not even considering malicious interference: what sorts of attacks will be discovered on this new UDP based shit, and what sorts of hacks will be required to mitigate them.

tlb 9y ago
I know that was the conventional wisdom, from back when backbone links were the bottleneck. But in the modern internet, almost all the congestion is at the edges. Since most traffic for games is server->client, most of the congestion will happen when several users are competing for the same customer link (DSL or cable modem). This already happens with streaming services, and people just yell at each other to stop downloading updates while I'm watching Netflix.
- kazinator 9y ago
  That could change one fine day when those edges get their stuff together. Indeed, the subscriber lines and surrounding edge hardware have not kept up with the times. Depending on where you are and who your provider is, chances are you're getting the same shitty line rates you had ten years ago (or more), though you have more memory, a bigger hard drive and a faster CPU, and the backbone is faster.
- zlynx 9y ago
  Anywhere with a lot of Gigabit Fiber installed, the congestion is _not_ at the edges. It's further in. If all of those installed Gigabit edges simultaneously used 1 Gbps download, it wouldn't happen. They'd get much less.
xxgreg 9y ago
Too late... Chrome already uses HTTP over UDP. https://en.wikipedia.org/wiki/QUIC https://en.wikipedia.org/wiki/QUIC

znpy 9y ago

Just use QUIC and advocate for its adoption.

Matthias247 9y ago
That doesn't necessarily solve the problem which is in focus here. The QUIC version which is available in browsers (ok, Chrome only) is not only the QUIC stream layer, but also the QUIC HTTP adaption layer. From javascript side you just interact with HTTP and use QUIC under the hood. However with HTTP you also get all HTTP semantics (headers, reliability, ordering inside of request/response streams, etc.). What is requested is an additional protocol and API which avoids all the overhead and just allows to send and receive messages with best effort - because games and other realtime applications may prefer to build their own reliability mechanism on top. The only way to use HTTP/QUIC for packetlike communication might be to send each packet inside a seperate HTTP request. But I guess that will have a super high overhead (lifecycle of a whole stream must be managed for a packet which actually has no lifecycle) and will most likely also not deliever the expected results (afaik HTTP on top of QUIC still has head-of-line blocking for request/stream establishment. Request headers must be received in order). New javascript APIs which are utilizing QUIC could work. However one would need to explore if QUIC is actually helpful for target applications, since it provides a stream semantic, whereas UDP is purely packet based. QUIC might also introduce similar issues like WebRTC to the server side: It's a complex protocol spanning multiple layers (everything from flow-control to encrytion). Therefore it will be hard to integrate into environments where no QUIC library is available. But that's only a feeling, since I haven't yet reviewed the QUIC specification in detail.

justsomedood 9y ago

Wouldn't this make it pretty easy to have browser clients unknowingly participate in DoS attacks?

dsl 9y ago
Yes. The only way this could be done safely is if you are required to establish a TCP connection, and then "upgrade" it to UDP. There are too many pointy sticks that developers could impale themselves on, with the side effect of creating DDoS vectors.
- deleted 9y ago
  [deleted]
- geofft 9y ago
  Can you do it safely if you're required to make an HTTPS request to the same hostname with some standardized request (a la CORS preflight) and get an answer back saying "Yes, this origin may connect to me on these UDP ports", and then hang onto that permission indefinitely? The nice thing about having a persistent permission instead of an upgrade on each request is that a service worker that's woken up by a push notification or similar can immediately send UDP traffic instead of doing a TCP (+ HTTPS?) handshake. Since it's restricted by origin (probably using literally the same mechanism CORS uses) and over HTTPS, a malicious actor can't DDoS anyone but themselves. If you're really worried, maybe extend it to allow the server to limit the duration of the permission and the maximum bandwidth, but I think you don't need that. EDIT: Oh, oops, binding to the hostname doesn't help because you can just repoint your hostname in DNS at someone else. You'd ideally need to bind it to the IP, in which case you definitely want it to be a time-limited permission. (But I think that attack is also feasible, though a bit harder, with the handshake-before-each-UDP-connection model. Just have the attacker set up a custom DNS server for their domain, which for any hostname sends you a low-TTL response pointing to the attacker's HTTPS server, and then a higher-TTL response to the victim. Each user gets pointed at a random hostname within that domain.)
  - jandrese 9y ago

xg15 9y ago

So if the main justification of this proposal is "WebRTC is too complicated", wouldn't that more speak for a WebRTC library and/or server geared towards games?

nitwit005 9y ago
Yes, it seems like a server side complexity issue should be a fixable problem without updating the standards. I suppose you'll still need to deploy a stun/turn server to deal with the NAT issues unless you're happy with IPv6 only, but that's not really something the standard can fix.
z3t4 9y ago
Last time I checked on WebRTC tutorials and examples was either too old and deprecated, or required the latest Chrome with some flags enabled. The best we have right now for real time streaming is HLS with up to 20 seconds or more delay. We had real time video chat 20 years ago, why can't we have it in the browser today !?
- TD-Linux 9y ago
  I think you checked too long ago. Appear.in, Jitsi, Discord, and Cisco Spark are all working with WebRTC now.
mrmoka 9y ago
As mentioned in the doc, one of the options is to simplify WebRTC by making some components optional to enable it's better adoption and easier to implement on the back-end as well as on front-end.
TD-Linux 9y ago
It sounds like you're describing HumbleNet: https://github.com/HumbleNet/HumbleNet https://github.com/HumbleNet/HumbleNet
- mrmoka 9y ago
  And with WebUDP life for those guys would be much easier.

deleted 9y ago

[deleted]

eecc 9y ago

Can't we just rewrite the Linux kernel in JavaScript and boot it off a browser ... /s (hopefully)

pdkl95 9y ago
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
nomadlogic 9y ago
netbsd beat you to this by 5 years or so: https://blog.netbsd.org/tnf/entry/kernel_drivers_compiled_to_javascript https://blog.netbsd.org/tnf/entry/kernel_drivers_compiled_to...
trelliscoded 9y ago
Why, yes. Yes you can. http://jslinux.org/ http://jslinux.org/

pdkl95 9y ago

> Requirements > 1. Security - it has to benefit from SSL. There is a lot more to security than transport-layer encryption and authentication. > Connection based UDP is too hard, so re-inventing TCP? > p2p is not reliable ... monetization Oh, you want require the SAaSS[1] model. > Simple to use The already-stated "requirements" are asking for something more complex than WebRTC. > Minimum header overhead Wait, are you thinking about using UDP to transport HTTP?! Do you even know what your MTU is? > WebRTC suffers from complexity That complexity exists for reason. Nowhere in this document is a discussion of the potential problems of using UDP or the ways tthe new service might be exploited by malicious actors. [1] Service as a Software Substitute

mrmoka 9y ago
> There is a lot more to security than transport-layer encryption and authentication. You are welcome to PR. > Connection based This could be explored: starting from simple handshake, all the way to fully connection based protocol. Open for discussion based on developer needs. > The already-stated "requirements" are asking for something more complex than WebRTC. You are welcome to highlight specifics that makes you think that way. > Wait, are you thinking about using UDP to transport HTTP?! Do you even know what your MTU is? UDP is not streamed but message based protocol. As WebSockets implement their transport layer over pure TCP, WebUDP could implement it's own layer over pure UDP for various reasons. > > WebRTC suffers from complexity > That complexity exists for reason. For P2P type communications, this complexity is perhaps reasonable. For Server-Client type communications not at all. > Nowhere in this document is a discussion of the potential problems of using UDP or the ways tthe new service might be exploited by malicious actors. This document is initial effort to bring public discussion to form a reasonable shape of what WebUDP could look like. You are welcome to participate.
- pdkl95 9y ago
  > UDP is not streamed but message based protocol. I'm very[1] familiar with the IP family of protocols. > Open for discussion If you don't know what your requirements are, you shouldn't be choosing a transport technology. It sounds like you want an library that wraps WebSockets or WebRTC and handles most of the complexity. > WebUDP could implement it's own [transport] layer over pure UDP Then you want TCP. The only reason to use UDP is to avoid the complexities of a transport layer. Transport reliability is very hard; this isn't something that is easy to re-implement by yourself in UDP. More importantly, I take it you don't know what your MTU is? The Maximum Transmission Unit[2] the maximum packet size. On ethernet-based networks, it's probably ~0-100 octets less than ethernet's 1500 octet MTU. You need to keep UDP packets under this limit, or they will fragment. Fragmented IP packets may not arrive at all and even when they do, the OS will wait until all fragments arrive before passing the data up to the app. If you're insane and send HTTP headers in each packet, you've wasted most of your data space. Each packet? Shouldn't we send headers in the first packet only? Except that every packet IS the "first packet" in stateless protocol like UDP. It's the transport features of TCP that create ordered-data semantics. [1] I used to write firmware for embedded systems. That included writing - from scratch, in Z80 asm - the entire network layer: ethernet (RealTek), ARP, IP, UDP, TCP, SNMP, HTTP, etc. [2] https://en.wikipedia.org/wiki/Maximum_transmission_unit https://en.wikipedia.org/wiki/Maximum_transmission_unit

soapdog 9y ago

Firefox OS had TCP[0] and UDP[1] sockets as Web APIs. They were quite pleasant to use as a developer and the only way to create a real mail client (needs TCP to implement POP, IMAP, SMTP in JS). I wish more Firefox OS APIs had become web standards. They would allow for some very powerful PWAs. [0]: https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/TPC_Socket_API https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/... [1]: https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/UDPSocket https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/...

mrmoka 9y ago
Those implementations were created to be utilised within FirefoxOS where applications are granted permissions by user when installing them. And access to several API would be strictly regulated by OS it self. In Web context this approach wouldn't work and would lead to security issues. Just like there was need or WebSockets (TCP), there is need for similar API for UDP but it cannot be pure access for creating UDP connections as this leads to many security concerns.
- soapdog 9y ago
  I am a fan of the "just stick a security popup and let people choose" option but I understand that is not the same as having proper security.
geofft 9y ago
Chrome OS supports the same thing: https://developer.chrome.com/apps/app_network https://developer.chrome.com/apps/app_network The SSH and mosh apps use a binding between the POSIX socket interface on the Native Client side and these APIs on the JS side.
jcranmer 9y ago
> Firefox OS had TCP[0] and UDP[1] sockets as Web APIs. They were quite pleasant to use as a developer and the only way to create a real mail client (needs TCP to implement POP, IMAP, SMTP in JS). The biggest problem with Firefox OS's TCP standard is that it used an event-driven model, which is somewhat at odds with more current promise-based thinking. The more natural version is to use something based on WHATWG Streams, but that spec has been stuck in vaporware-land for years. > I wish more Firefox OS APIs had become web standards. They would allow for some very powerful PWAs. The TCP specification actually was undergoing standardization (reformatted to use the streams API): https://www.w3.org/TR/tcp-udp-sockets/ https://www.w3.org/TR/tcp-udp-sockets/ . The problem was the working group ended up closing down, and since the specification wasn't suitable for use on webpages, it ended up with nobody to host it.

smcdow 9y ago

Maybe you'd have more interest if you wrote up a proper RFC.

mrmoka 9y ago
This is collaborative effort. I act from my capabilities, but people with certain skillset are welcome to contribute with proper RFC.

shurcooL 9y ago

Are people aware of https://www.w3.org/TR/tcp-udp-sockets/ https://www.w3.org/TR/tcp-udp-sockets/? I didn't see it mentioned so far.

mrmoka 9y ago
This spec been there for very long time, and has been adopted by FirefoxOS (deprecated platform). Which exposes low-level access to establish pure TCP and UDP connections with permissions flow by environment. It exposes many security concerns, that's why WebSockets were more favourable over TCPSocket. We want similar for UDP.
- LunaSea 9y ago
  Not having raw TCP means you can't speak to any existing TCP protocol through a browser. It might not be a useful feature but I think that not taking it into account is an issue because most use cases can't be implemented with WebSockets.
  - mrmoka 9y ago
    Ability to connect to raw TCP or UDP from a browser is a major security hole. Due to that, WebSockets were created were handshake is handled by browser transparently from developer ensuring port scanning is not possible. As well as to preserver origin-based security model of HTTP. Which we want for WebUDP as well.

TD-Linux 9y ago

I think you're going to need a stronger argument for "Why not WebRTC", or at least concrete proposals about what parts of the API you would change. For example, "SDP parsing is too complex, have a JS API to set up a client-server connection without a SDP". IMO the most complex parts of WebRTC are the SRTP-DTLS encryption (except you also specified TLS as a requirement for Web UDP), and STUN/TURN (which are optional and not required for client-server).

mrmoka 9y ago
This is valuable input, you are welcome to contribute in form of PR!
- TD-Linux 9y ago
  Well, the problem is that I currently think WebRTC 1.0 is sufficient. For the example I gave, I think a simple JS library to write out the SDP is a perfectly fine solution. So I'm more asking, what did you find wrong with WebRTC?
  - mrmoka 9y ago
    Simply look at present state of WebRTC adoption by back-end services for use in server-client cases. Fist of all it is not designed for server-client cases. Second, after so many years, it is still not well adopted and used for server-client cases due to it's complexity on both sides - back-end implementation and front-end usage. If you compare it to speed of adoption of WebSockets, variety of WebSockets implementations and how much it is used commercially. There are many conversations by many developers who as well attempted using WebRTC for server-client communications, and it is apparent trend. One of the developers of WebRTC team at Google who worked on DataChannel and network code admits himself that their team is aware of complexity and difficulties with WebRTC in server-client cases: https://news.ycombinator.com/item?id=13266874 https://news.ycombinator.com/item?id=13266874
    - LunaSea 9y ago

Wofiel 9y ago

Anyone interested in this might find some enlightenment in Glenn Fiddler's whitepaper. [1] It talks about the issues with TCP-based connections, WebSockets, QUIC, WebRTC and provides a solution (with code) to doing UDP in browser. [1] https://gafferongames.com/post/why_cant_i_send_udp_packets_from_a_browser/ https://gafferongames.com/post/why_cant_i_send_udp_packets_f...

gafferongames 9y ago
Update: there is now a full browser-based implementation of netcode.io too! https://github.com/RedpointGames/netcode.io-browser https://github.com/RedpointGames/netcode.io-browser

lxtx 9y ago

Posted this recently in another thread, but maybe someone will find https://github.com/seemk/WebUdp https://github.com/seemk/WebUdp useful as there have been many WebRTC threads lately. It's a WebRTC DataChannel server implementation for out of order, unreliable UDP traffic for browsers that has built-in SDP signaling and STUN.

mrmoka 9y ago
Just looking at the complexity of "minimal" implementation only highlights the need for different solution.

remline 9y ago

SCTP would be the logical choice for supporting both streams and messages. No one really wants to support a network with the evil of arbitrary UDP from the browser. In SCTP, the handshake combined with crypto tricks can allows a server to make sure the initiator stores a larger cookie than it needs to hold for verification, throttling the DDOS riffraff.

mrmoka 9y ago
SCTP have been mentioned in the repo: https://github.com/Maksims/web-udp-public/issues/1#issuecomment-318179584 https://github.com/Maksims/web-udp-public/issues/1#issuecomm...
- remline 9y ago
  The reasoning there is kind of lame, every filter knows how to pass SCTP or UDP and doesn't pass SCTP since it is unpopular and UDP because stopping it is most of why you are filtering. Making an SCTP web standard would improve endnode support (and actual app use) which is beginning to wane and are SCTPs adoption problems.
  - mrmoka 9y ago
    It is indeed a bit like chicken-and-egg situation here. But SCTP implements reliability and ordered delivery making it more of an alternative to TCP, than a solution for low-latency communication with cases where reliability and/or ordered delivery is not required.
    - rjsw 9y ago
      There is also DCCP [1]. [1] https://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol https://en.wikipedia.org/wiki/Datagram_Congestion_Control_Pr...
      - remline 9y ago
        I'm not familiar with DCCP, but as long as browsers don't get access to DCCP-UDP encapsulation without some work by the user it seems like another alternative to use to use web security considerations as leverage to ween a critical mass off of UDP.

mnarayan01 9y ago

For this to be taken seriously, I think you need to demonstrate that you're capable of using WebRTC to do what you need. Without a decent nod in that direction, people are going to think that you're just not aware of the potential complexities.

mrmoka 9y ago
Worth mentioning again: this effort is to explore server-client low-latency, not peer-to-peer scenarios which WebRTC solves well. And this is collaborative effort, not personal. So all input is welcome. I've used WebRTC for p2p and server-client cases, and it is nightmare for later. And many other developers have expressed very similar experience when it comes to server-client cases. Even more, after many years we see very little adoption of WebRTC for server-client cases due to it's complexity. WebSockets on the other hand took very little time to get adopted by many back-end platforms as well as browser vendors. I wrote my own WebSockets solution long time ago on .Net before 4.5 .Net was released (includes own WebSockets implementation).

jstewartmobile 9y ago

So many of these comments are like "UDP is not TCP!" or "Muh TCP guarantees!", then they go on to mention WebRTC?!!! I mean, if you're streaming audio and video Real Time, is there really any point to TCP? If a few frames get dropped, then bursted back once the connection stabilizes, does that improve the user experience in any way? WebRTC seems like a perfect candidate for UDP communications for the actual media streams.

mrmoka 9y ago
WebRTC is best option for media streams today for peer-to-peer cases. The goal of the topic is to explore simple option for server-client communication using low-latency communication, without reliability and without ordered delivery. WebRTC can be used for such case, although it is not designed for it. Due to that implementation is very complex and not much adopted. This is something we trying to explore, either new API or simplifications to WebRTC to make it simple choice for UDP in server-client scenarios.
- detaro 9y ago
  Given the kind of feedback happening (and my initial reaction admittedly was similar), maybe a different name would help with perception (I'm already not a big fan of "WebSockets", but "WebTCP" would have been worse), promoting the goals over the implementation detail of UDP?
  - mrmoka 9y ago
    If there is alternative transport protocol to enable low-latency delivery as efficient as UDP, then it is worth exploring. UDP - is something been used by many industries for long time and is well known protocol to make a foundation from.
- jstewartmobile 9y ago
  It just seems like most real-life usages of WebRTC are either media-centric where TCP does more harm than good, or multiplayer scenarios where it's a wash since TCP's ordering is a pro while TCP's overhead is a con.

kelnos 9y ago

This seems to come up every now and then, and I see the same arguments, and they're still not compelling. WebRTC data channels in unreliable mode will work just fine. Is it as easy as opening up a WebSocket connection? No, it's not. Is it as easy on the server side as accepting a WebSocket connection? Also no. But it really isn't that hard[0], and people have built libraries to help you out. So just use one, and move on with your life. And you also benefit from a standard that has been fleshed out over multiple years by some very smart (if imperfect) people. On the browser side, it's already supported by all major browsers, with the notable exception of iOS Safari (which should change this fall with the release of iOS 11)[1]. Even though it's not ideal, you can fall back to WebSocket for the few holdouts. [0] Source: I've done it before, building it from scratch. [1] https://caniuse.com/#feat=rtcpeerconnection https://caniuse.com/#feat=rtcpeerconnection

geocar 9y ago

I've written a WebRTC "server" that can establish such a connection (and also acts as it's own STUN/TURN server) and hand off sockets to a local process. WebRTC isn't very complicated. The hardest part is probably ICE, which basically involves each point telling eachother what they see, and potentially consulting a third party (STUN/TURN). I'd love to see more magic there, but once that's in-place, I don't see what's so hard about just using DataChannels. One idea might be to put signalling into HTTP headers, e.g. have the client and server introduce something like: ICE: sdp-desc... and if so, allow WebRTC to skip the ICE negotiation step if speaking to the server.

ksec 9y ago

I read 5G is doing something similar, or rather something new to solve this problem. They are completely remaking the TCP/IP stack. Anyone knows anything about that?

dr_hooo 9y ago
The ETSI NGP ISG[1] is looking at next generation protocols, also in the context of 5G. "This ISG is seen as a transitional group i.e. a vehicle for the 5G community (and others of interest) to first gather their thoughts and prepare the case for the Internet community’s engagement in a complementary and synchronised modernisation effort." The efforts seems to be in an quite early stage for now (architecture, models, requirements, etc). I personally don't see TCP/IP going anywhere with 5G, but we may see more parallel deployments of protocols within isolated 5G network slices. [1] http://www.etsi.org/technologies-clusters/technologies/next-generation-protocols http://www.etsi.org/technologies-clusters/technologies/next-...

captainmuon 9y ago

This seems to propose that you can only connect to a certain server, similar to the same-origin-policy. What I would really love instead is the possibility to connect to arbitrary IPs to be able to implement real P2P. The linked posts dismiss this early because of the possibility to cause DDOS, but really, you can already do that from a hacked desktop "Quake", so there is no harm in being able to do it from a browser-based "Quake". What you'd have to prevent is drive-by use of UDP, not use of UDP period. I would propose having two HTML profiles in future, HTML document, and HTML application (and maybe HTML legacy). HTML document would be restricted in what you can do, and would be primarily for reading Hypertext. For HTML application you would have to go through a few clicks to install or activate it - now you are going to say that people will just click it away, but that is already the case with current desktop app installers, so it is not more insecure! An application profile page will be able to access the net just like any other native application. Most importantly, it will be able to bypass same-origin policy and send UDP and TCP anywhere - but not with credientials of course. You'd still have the problem of being able to probe internal networks, and being able to manipulate UPnP routers. For the first, the network admin could have a group profile setting or similar to disable this kind of access. For the second, browsers could selectively block this on a case-by-case basis if needed. For the problem of DDOS, I think we should not let that restrict us from implementing useful technologies. Rather we should fix it at the source. For example, maybe one could lock down certain routes if an attack is detected. All traffic along these routes is throttled, unless you send along a proof-of-work token. I'm just making this up, but my point is that I think we haven't exhausted all options here.

bewo001 9y ago
For p2p, you already have the webrtc data channel which handles all the nasty NAT traversal and DDoS issues. Its browser API should be less volatile now than it has been in the past. Implementing a WebRTC data channel endpoint in a server is not for the faint of heart, though. You would have to implement a lot of complex RfCs.
- captainmuon 9y ago
  Yeah, but you need a central server, right? You cannot make a DHT for example, like Kademlia or trackerless Bittorrent.

deleted 9y ago

[deleted]

RajuVarghese 9y ago

One thing that I do not see mentioned here is multicast. Are there any advantages? Watching a live sports game, for instance. Since multicast is connection-less and sent only over UDP, the more distant discussion about introducing multicast into browsers never takes place. Having used a multicast video stream for many years in an enterprise setting I can unequivocally state that this would decrease network utilization. Especially in the years to come as the interwebs get clogged up with broadcast-type data.

mrmoka 9y ago
The main goal of this effort is to explore server-client communication scenarios.
wbl 9y ago
ISPs are not supporting multicast over the public internet.
- RajuVarghese 9y ago
  They will if it becomes a standard way of broadcasting. They will save quite a bit of network load.
  - fulafel 9y ago
    The tech has been standardized as IPTV, and it sees a fair bit of use. But not over the public internet (for one, because ISPs don't support it...)

Matheus28 9y ago

I'd also like to draw some attention to this proposal: https://github.com/Maksims/web-udp-public/issues/6 https://github.com/Maksims/web-udp-public/issues/6

gafferongames 9y ago
This proposal lacks challenge/response and makes game server vulnerable to being used in DDoS amplification attacks if they use request/response pattern. Also, a proposal without packet encryption in 2017, seriously?!

LinuxBender 9y ago

Most home users probably allow UDP out of their network. How many businesses by default allow UDP outbound on any port? Will the documentation/RFC's encourage folks to fail gracefully if UDP is not supported in their network? Could this spec include support for SRV records? It isn't allowed in http/1.1.