Viewing profile — vasilvv

> 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 t…

For what it's worth, C++17 added [[nodiscard]] to address this issue.

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 …

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 …

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 bala…

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…

> 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…

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 …

I'm not sure where rustls comes from -- Chrome uses BoringSSL, and last time I checked, Mozilla implementation used NSS.

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 …

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 t…

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 byt…

> 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 …

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 vi…

(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 li…

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…

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/quict…

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 eve…

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 d…

> 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…

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 Somewh…