Hey dang, I don't think my blog is a repost. It links the Cloudflare announcement but the content is completely different (and actually funny). Is there any way you could restore it?
It's not that it's a repost; it's that it's mostly reporting on the content of another article. In such cases it's standard HN practice to prefer the latter, as the guidelines say (and have said since ancient times). It's not that you did anything wrong! and I'm sorry, I know it sucks to have an article doing well on the frontpage and then plummet for no obvious reason. But from a mod practice point of view this is a pretty clear call.
(OP of the Cloudflare blog & submission here) I think kixelated is saying enough stuff beyond our post that he deserves the credit for and this shouldn't be treated as a dupe. (emailed to say as much also)
I linked the URL to their relay but otherwise all of the libraries, demos, rants, jokes are my own. I can remove the link to their post if that would help, or I could get Cloudflare's blessing. It's just a bit frustrating.
Hey HN, I've spent the last few years working on an open source WebRTC replacement using new web technologies. It's being standardized by the IETF, but progress is slow, so I finally decided to get serious and go full-time making an application out of it. Let me know what you think!
Logs should be bursty, because they're most useful when debugging rare issues. If you have identical log lines, then that should have been a metric instead.
Metrics should be sampled based on frequency, because they deduplicate. I'm a huge fan of logarithmically sampling metrics.
I tried using SCTP before QUIC. Unfortunately, while the API looks like you can mix reliable/unreliable messages, in reality the transport doesn't support it because of how FORWARD-TSN works. There were some other pretty fundamental blockers too.
Fun fact, at one point it was better (and cheaper) to serve Telstra viewers out of LA instead of our Sydney datacenter because of the mess that is Australia internet infrastructure.
QUIC supports self-signed certs if LetsEncrypt is too corporate for you. WebTransport lets you specify the certificate fingerprint (sha256) much like WebRTC, although it does enforce that the certificate is valid for <14 days so it will need to be ephemeral.
> A client can theoretically detect a bandwidth fall (or even guess it) while loading a segment, abort its request (which may close the TCP socket, event that then may be processed server-side, or not), and directly switch to a 360p segment instead (or even a lower quality). In any case, you don't "need to" wait for a request to finish before starting another.
HESP works like that as far as I understand. The problem is that dialing a new TCP/TLS connection is expensive and has an initial congestion control window (slow-start). You would need to have a second connection warmed and ready to go, which is something you can do in the browser as HTTP abstracts away connections.
HTTP/3 gives you the ability to cancel requests without this penalty though, so you could utilize it if you can detect the HTTP version. Canceling HTTP/1 requests especially during congestion will never work through.
Oh and predicting congestion is virtually impossible, ESPECIALLY on the receiver and in application space. The server also has incentive to keep the TCP socket full to maximize throughput and minimize context switching.
> From this, I'm under the impression that this article only represents the point of view of applications where latency is the most important aspect by far, like twitch I suppose, but I found that this is not a generality for companies relying on live media.
Yeah, I probably should have went into more detail but MoQ also uses a configurable buffer size. Basically media is delivered based on importance, and if a frame is not delivered in X seconds then the player skips over it. You can make X quite large or quite small depending on your preferences, without altering the server behavior.
> But perhaps another solution here may be to update DASH/HLS or exploit some of its features in some ways to reduce that issue. As you wrote about giving more control to the server, both standards do not seem totally against making the server-side more in-control in some specific cases, especially lately with features like content-steering.
A server side bandwidth estimate absolutely helps. My implementation at Twitch went a step further and used server-side ABR to great effect.
Ultimately, the sender sets the maximum number of bytes allowed in flight (ex. BBR). By also making the receiver independently determine that limit, you can only end up with a sub-optimal split brain decision. The tricky part is finding the right balance between smart client and smart server.
Interesting points and insight, thanks. I should probably look more into it.
My point was more about the fact that I found the article unfairly critical towards live streaming through DASH/HLS by mainly focusing on latency - which I understand may be one of the (or even the) most important points for some use cases, but weren't much on the cases I've worked on, where replacing DASH would be very complex.
This was kind of acknowledged in the tl;dr, but I still found the article unfair at this level.
