SoylentNews is people
SoylentNews
(This is the seventh of many promised articles which explain an idea in isolation. It is hoped that ideas may be adapted, linked together and implemented.)
Using UDP for streaming video seems idiotic and is mostly deprecated. However, it has one huge advantage. It works really well with a large number of concurrent users. Within reason, it is worthwhile to maximize this number and minimize cost. Network games can be quite intensive in this regard with SecondLife previously rumored to having two users per server and WorldOfWarcraft having 20 users per server. At the other extreme, Virtudyne (Part 1, Part 2, Part 3, Part 4) aimed to run productivity software with 20 million users per server. That failed spectacularly after US$200 million of investment.
Maintaining more than 10000 TCP connections requires a significant quantity of RAM; often more than 1MB per connection. A suitably structured UDP implementation doesn't have this overhead. For example, it is possible to serve 40 video streams from a single-threaded UDP server with a userspace of less than 1MB and kernel network buffers less than 4MB. All of the RAM previously allocated to TCP windowing can be re-allocated to disk caching. Even with a mono-casting implementation, there are efficiency gains when multiple users watch the same media. With stochastic caching techniques, it is easy for network bandwidth to exceed storage bandwidth.
There is another advantage with UDP. FEC can be sent speculatively or such that one resend may satisfy multiple clients who each lack differing fragments of data. It is also easy to make servers, caches and clients which are tolerant to bit errors. This is particularly important if a large quantity of data is cached in RAM for an extended period.
So, what is a suitable structure for a UDP server? Every request from a client should incur zero or one packets of response. Ideally, a server should respond to every packet. However, some communication is obviously corrupted, malformed or malicious and isn't worth the bandwidth to respond. Also, in a scheme where all communication state is held by a client and all communication is pumped by a client, resends are solely the responsibility of a client.
From experience, it is wrong to implement a singleton socket or a set of client sockets mutually exclusive with a set of server sockets. Ideally, library code should allow multiple server sockets and multiple client sockets to exist within userspace. This facilitates cache or filter implementation where one program is a client for upstream requests and a server for downstream requests.
(Score: 0) by Anonymous Coward on Thursday July 06 2017, @06:29AM (3 children)
UDP is the best you can do???
Wake me when you invent streaming video over ICMP. And make it work through NAT.
Seriously.
(Score: 1, Interesting) by Anonymous Coward on Thursday July 06 2017, @10:25AM (2 children)
If you want to see another thing UDP can do that TCP cannot, see here. [mosh.org]
(Score: 3, Informative) by Marand on Thursday July 06 2017, @01:39PM
Mosh is excellent, glad someone mentioned it. The ability to hop IPs and its tolerance for loss of link makes it especially suited to use over mobile networks, where roaming and wifi APs can result in frequent IP changes, and the prediction capabilities make it nicer to use over high-latency links than ssh itself.
Bit of a shame that it can't handle mouse input or port forwarding, though, so I still have to fall back to using ssh for those things sometimes.
(Score: 0) by Anonymous Coward on Thursday July 06 2017, @05:01PM
To be fair, Mosh could have been written to use TCP as well. It wouldn't have worked the best, but it would have been doable. Most of the intelligence in mosh is in the application logic, not the UDP over TCP. The only real benefit for UDP over TCP is that UDP allows for a larger amount of out-of-band data without relying on a second connection and can discard data you don't really need. But something like mosh doesn't have a large amount of OOB need, so the data difference isn't that large.
However, the above doesn't not mean I think UDP is better or worse than TCP, they are just made for different things. There seems to be some sort of rediscovery of UDP going on by the next gen of coders, and they are going a bit overboard as to its "miraculous" abilities.
(Score: 2) by The Mighty Buzzard on Thursday July 06 2017, @09:06AM (1 child)
Kudos on an interesting stream of though. I'm quite enjoying the series.
My rights don't end where your fear begins.
(Score: 2) by cafebabe on Thursday July 06 2017, @10:52PM
This finishes with a reference implementation. There are licencing problems with previous implementations but it is a joy to transfer 80GB without bit errors, have more than 2^17 requests pending when recursing directories or serve 40 video streams with one userspace process which is less than 1MB and UDP buffers less than 4MB.
I hope to extend low performance implementations down to systems with 64KB RAM. This would include micro-controllers or something like a Commodore 64. This may seem optimistic but I refrain from specifying smaller systems.
1702845791×2
(Score: 0) by Anonymous Coward on Thursday July 06 2017, @05:13PM (3 children)
Seriously.
If your streaming protocol uses ICMP then you avoid any QoS policy which affects UDP specifically. Low latency highly responsive ping is something ISPs tend to want to provide, in some cases ICMP traffic is not throttled, and sometimes ICMP is not even metered. Your streaming protocol could enjoy the benefits of policy loopholes where such loopholes exist, until your protocol becomes popular enough for ISPs to notice and apply QoS.
In terms of protocol efficiency, UDP and ICMP have exactly the same header size (8 bytes) and the headers contain almost equivalent information. Although ICMP does not have ports, there are two 16-bit values in the header which can be used exactly like ports. These values are the Identifier and the Sequence Number, and in practice, NAT translates one of these values and not the other. The challenge of making an ICMP based transport work through NAT is to detect which header field NAT translates and use the other as a port number for your transport protocol.
Since ICMP and UDP are almost equivalent, you could design a protocol which defaults to transport over ICMP with fallback to UDP when necessary.
(Score: 2) by cafebabe on Thursday July 06 2017, @10:59PM (2 children)
I've ran a protocol outside of TCP, UDP or ICMP. Packets are shorter than UDP or ICMP but the lack of UDP port number incurs O(n^2) processor load when multiple applications wish to receive packets. Applications also require elevated privileges to establish a connection. Another limitation is that firewalls drop these unusual packets. So, UDP is satisfactory even if it isn't optimal.
1702845791×2
(Score: 0) by Anonymous Coward on Friday July 07 2017, @05:26AM (1 child)
Yes with raw sockets every listening process receives every packet and each process must drop packets which are addressed to ports belonging to other processes. The point still stands that ICMP can avoid QoS policy. Giant telcos run firewalls which allow ICMP and which only shape TCP and UDP traffic. When IPv6 is available and NAT is not done then firewalls are even less restrictive and allow all manner of unusual traffic to pass normally. Where NAT restricts ICMPv4 traffic to ordinary pings only, I have successfully exchanged ICMPv6 reserved message type 200 because without the need for NAT there is also no reason to drop the packets.
(Score: 0) by Anonymous Coward on Friday July 07 2017, @06:35PM
AC is right! NAT is preventing progress! No one dares design a protocol that is not encapsulated in one of the big three (TCP, UDP, ICMP) if everything else is blocked by NAT. We need IPv6 to bring an end to NAT so protocol designers can innovate again!