3 ms·

> I wonder what percentage of http traffic is redundant compression dictionaries. How much could this actually help in theory? A lot of times you will send a (

by derf_ 2y ago

> I wonder what percentage of http traffic is redundant compression dictionaries. How much could this actually help in theory? A lot of times you will send a (possibly large) blob of text repeatedly with a few minor changes. One example I've used in practice is session descriptions (SDP) for WebRTC. Any time you add/remove/change a stream, you have to renegotiate the session, and this is done by passing an SDP blob that describes all of the streams in a session in and out of the Javascript Session Establishment Protocol (JSEP) API on both sides of the connection. A video conference with dozens of participants each with separate audio and video streams joining one at a time might require exchanging hundreds or even thousands of SDP messages, and in large sessions these can grow to be hundreds of kB each, even though only a tiny portion of the SDP changes each time. Now, you could do a lot of work to parse the SDP locally, figure out exactly what changed, send just that difference to the other side, and have it be smart enough to patch its local idea of the current SDP with that difference to feed into JSEP, test it on every possible browser, make it robust to future changes in the SDP the browser will generate, etc. OR You could just send each SDP message compressed using the last SDP you sent as the initial dictionary. It will compress really well. Even using gzip with the first ~31 kB of the previous SDP will get you in the neighborhood of 200:1 compression[0]. Now your several-hundred kB SDP fits in a single MTU. I'm sure WebRTC is not the only place you will encounter this kind of pattern. [0] Not that either gzip or using part of a document as a dictionary are supported by this draft.

toast0 2y ago
> Now, you could do a lot of work to parse the SDP locally, figure out exactly what changed, send just that difference to the other side, and have it be smart enough to patch its local idea of the current SDP with that difference to feed into JSEP, test it on every possible browser, make it robust to future changes in the SDP the browser will generate, etc. I work with WebRTC outside a browser context, and we signal calls with simpler datastructures and generate the SDP right near the WebRTC Api. Our SFU doesn't ever see an SDP, because SDP is a big messy format around simpler parts --- it's easier to just communicate the simpler parts, and marshal into SDP at the API border. Even for 1:1 calls, we signal the parts, and then both ends generate the SDP to feed to WebRTC. IMHO, you're going to have to test your generated SDPs everywhere anyway, regardless of if clients or servers generate them. Well managed compression would certainly help reduce SDP size in transit, but reduce, reuse, recompress in that order.

by derf_ 2y ago

toast0 2y ago

> Now, you could do a lot of work to parse the SDP locally, figure out exactly what changed, send just that difference to the other side, and have it be smart enough to patch its local idea of the current SDP with that difference to feed into JSEP, test it on every possible browser, make it robust to future changes in the SDP the browser will generate, etc. I work with WebRTC outside a browser context, and we signal calls with simpler datastructures and generate the SDP right near the WebRTC Api. Our SFU doesn't ever see an SDP, because SDP is a big messy format around simpler parts --- it's easier to just communicate the simpler parts, and marshal into SDP at the API border. Even for 1:1 calls, we signal the parts, and then both ends generate the SDP to feed to WebRTC. IMHO, you're going to have to test your generated SDPs everywhere anyway, regardless of if clients or servers generate them. Well managed compression would certainly help reduce SDP size in transit, but reduce, reuse, recompress in that order.