vasilvv

8 ms·

1.
by vasilvv 1mo ago
Counterintuitively, seeing things can alter the perception of individual sounds you're hearing: https://en.wikipedia.org/wiki/McGurk_effect
2.
by vasilvv 4mo ago
> though going the in-house approach would warrant keeping an eye on the relevant kernel commits like a hawk to avoid missing bug fixes like these. These in-house implementations tend to have less eyeballs than the kernel. This is somewh
3.
by vasilvv 8mo ago
For what it's worth, C++17 added [[nodiscard]] to address this issue.
4.
by vasilvv 11mo ago
The story here is a bit complicated. WebTransport is, in some sense, an evolution of RTCQuicTransport API, which was originally meant to solve the issues people had with SCTP/DTLS stack used by RTCDataChannel. At some point, the focus
5.
by vasilvv 1y ago
This sounds very similar to how base::WeakPtr works in Chromium [0]. It's a reasonable design, but it only works as long as the pointer is only accessed from the same thread it is created. [0] https://chromium.googlesource.c
6.
by vasilvv 2y ago
The article seems to make an assumption that the application backend is in the same datacenter as the load balancer, which is not necessarily true: people often put their load balancers at the network edge (which helps reduce latency when t
7.
by vasilvv 2y ago
Isn't this the problem that JSON5 (and probably other similar projects) is supposed to solve? Both JSON (as defined in the RFC) and JSON5 have a nice property of being well-defined, meaning that you can use different libraries in diffe
8.
by vasilvv 2y ago
> HTTP → RFC-2616 says in section 19.3 says "we recommend that applications ... recognize a single LF as a line terminator...." In other words it is perfectly OK for an HTTP client or server to accept CR-less HTTP requests or r
9.
by vasilvv 2y ago
W3C generally requires Working Group participants to provide IPR licensing commitments for the spec in question [0]. As far as I understand, higher level of specification maturity implies stronger level of obligations, though the specifics
10.
by vasilvv 2y ago
I'm not sure where rustls comes from -- Chrome uses BoringSSL, and last time I checked, Mozilla implementation used NSS.
11.
by vasilvv 2y ago
Generally, L2 networks are engineered with the assumption that they will carry TCP, and TCP performs really poorly with high loss rates (depends on the specific congestion control used, but the boundary can be anywhere between 1% and 25%),
12.
by vasilvv 3y ago
It's possible to build something similar on top of TCP, see Minion [0] for an example. There are multiple reasons why this is less practical than building on top of UDP, the main two being, from my perspective: (1) this requires coope
13.
by vasilvv 3y ago
QUIC requires the initial handshake packets to be at least 1200 bytes, and sets the anti-amplification limit of 3x [0]. This means that the server can typically send up to 3600 bytes in response (unless the client's handshake message e
14.
by vasilvv 4y ago
> There seems to be not too much interest in or hype about WebTransport. I feel like this is partially because the main value of the API comes from working better on lower-quality networks, rather than providing the ability to do somethi
15.
by vasilvv 4y ago
There's a simple echo server demo at https://webrtc.internaut.com/wt/ If you want an example of an application that actively benefits from using WebTransport, there's a proposed video streaming protocol calle
16.
RFC 9170: Long-Term Viability of Protocol Extension Mechanisms(rfc-editor.org)
2 points by vasilvv 5y ago|0 comments
17.
RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport(rfc-editor.org)
3 points by vasilvv 5y ago|0 comments
18.
by vasilvv 6y ago
(I work for Google, opinions my own) For YouTube, the CPU cost of QUIC is comparable to TCP, though we did spent years optimizing it. [0] has a nice deep dive. Other CDN vendors like Fastly seem to have the similar experience [1]. I believ
19.
by vasilvv 6y ago
I am not sure I follow this. WebTransport defines a way to transfer arbitrary data over HTTP/3, it's not a media protocol. I expect that a well-defined media transfer protocol will eventually emerge for media over WebTransport,
20.
by vasilvv 6y ago
Really glad to see people excited about this! If anyone is wondering if this is already implemented anywhere, we're currently experimenting with it in Chrome: https://web.dev/quictransport/ -- I'd be curious
21.
by vasilvv 6y ago
It will never get out-of-sync because TCP guarantees that the bytes will be delivered in the same order they've arrived. The best approach is typically put a length in front of every message. The good things about that approach are: 1
22.
by vasilvv 6y ago
Most of the common TCP congestion control algorithms (Reno, Cubic) are loss-based: they try to send more and more data until the link no longer can buffer all of the packets, and drops some of them. Naturally, this approach requires the bu
23.
by vasilvv 6y ago
> By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]? Different environments benefit from different algorithms so I don't see why. It's a "reasonable default", in the
24.
by vasilvv 7y ago
There's a proposal that would let video encoding be accelerated without going through the entire WebRTC pipeline: https://github.com/WICG/web-codecs/blob/master/explainer.md Somewhat tangentially re