6 ms·

> There is a lot more to security than transport-layer encryption and authentication. You are welcome to PR. > Connection based This could be explored: start

by 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
- mrmoka 9y ago
  > I'm very[1] familiar with the IP family of protocols. Great, you have an expertise to contribute. And with this discussion you already are. > 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. There are "libraries" that wrap over some protocols. They don't make adoption of underlying technology easier, WebRTC in this case. This effort is to establish clear requirements, not yet to propose exact solution. So this discussion is just a process of establishing those requirements. High level requirements are clearly stated in the document, and important one is: simplicity. Currently there is no simple solution for low-latency server-client communication. > > 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. Layer on top doesn't have to involve full on replication of TCP techniques or alternatives. Just like WebSockets only adds very little to pure TCP in form of a data framing (header) for messages. > 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. This is really valuable input, and is exactly what is needed to fuel further requirements for an implementation. You know, you can provide valuable input without trying to "argue" ;)
  - cesarb 9y ago
    All this discussion about UDP and MTU reminded me of an old StackOverflow answer of mine (https://stackoverflow.com/a/276096 https://stackoverflow.com/a/276096): "Alternative answer: be careful to not reinvent the wheel. TCP is the product of decades of networking experience. There is a reason for every or almost every thing it does. It has several algorithms most people do not think about often (congestion control, retransmission, buffer management, dealing with reordered packets, and so on). If you start reimplementing all the TCP algorithms, you risk ending up with an (paraphasing Greenspun's Tenth Rule) "ad hoc, informally-specified, bug-ridden, slow implementation of TCP". If you have not done so yet, it could be a good idea to look at some recent alternatives to TCP/UDP, like SCTP or DCCP. They were designed for niches where neither TCP nor UDP was a good match, precisely to allow people to use an already "debugged" protocol instead of reinventing the wheel for every new application."
mnarayan01 9y ago
> 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. As soon as your message exceeds the MTU, things get complicated. Sure you can layer something to re-assemble, but if packets are dropping, this is going to start getting problematic really fast. And if packets are not dropping, then TCP shouldn't overly increase latency anyway.
- mrmoka 9y ago
  This is something that worth exploring further to identify if it is a requirement for a WebUDP implementation.
- wbl 9y ago
  Packets are always dropping over wireless. In games and VOIP you skip and wait for the next one.

by mrmoka 9y ago

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

mrmoka 9y ago
> I'm very[1] familiar with the IP family of protocols. Great, you have an expertise to contribute. And with this discussion you already are. > 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. There are "libraries" that wrap over some protocols. They don't make adoption of underlying technology easier, WebRTC in this case. This effort is to establish clear requirements, not yet to propose exact solution. So this discussion is just a process of establishing those requirements. High level requirements are clearly stated in the document, and important one is: simplicity. Currently there is no simple solution for low-latency server-client communication. > > 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. Layer on top doesn't have to involve full on replication of TCP techniques or alternatives. Just like WebSockets only adds very little to pure TCP in form of a data framing (header) for messages. > 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. This is really valuable input, and is exactly what is needed to fuel further requirements for an implementation. You know, you can provide valuable input without trying to "argue" ;)
- cesarb 9y ago
  All this discussion about UDP and MTU reminded me of an old StackOverflow answer of mine (https://stackoverflow.com/a/276096 https://stackoverflow.com/a/276096): "Alternative answer: be careful to not reinvent the wheel. TCP is the product of decades of networking experience. There is a reason for every or almost every thing it does. It has several algorithms most people do not think about often (congestion control, retransmission, buffer management, dealing with reordered packets, and so on). If you start reimplementing all the TCP algorithms, you risk ending up with an (paraphasing Greenspun's Tenth Rule) "ad hoc, informally-specified, bug-ridden, slow implementation of TCP". If you have not done so yet, it could be a good idea to look at some recent alternatives to TCP/UDP, like SCTP or DCCP. They were designed for niches where neither TCP nor UDP was a good match, precisely to allow people to use an already "debugged" protocol instead of reinventing the wheel for every new application."

mnarayan01 9y ago

> 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. As soon as your message exceeds the MTU, things get complicated. Sure you can layer something to re-assemble, but if packets are dropping, this is going to start getting problematic really fast. And if packets are not dropping, then TCP shouldn't overly increase latency anyway.

mrmoka 9y ago
This is something that worth exploring further to identify if it is a requirement for a WebUDP implementation.
wbl 9y ago
Packets are always dropping over wireless. In games and VOIP you skip and wait for the next one.