
Salsify – A New Architecture for Real-time Internet Video - keithwinstein
https://snr.stanford.edu/salsify
======
jremmons
Hi everyone! I am one of the authors of Salsify. Ask me anything!

~~~
aidenn0
A practical issue I've seen with high-bandwith non-TCP transports (including
video over RTP) is how they behave in the presence of multiple other streams
on the line; when bandwidth becomes limited often you get one winner and a
bunch of loser streams. Does salsify address this at all?

~~~
keithwinstein
It's not a focus of this project, but in a different project we have set up
some pretty careful measurements (running every few days) to test whether this
happens to different congestion-control schemes, including ones like CUBIC
(Linux's default for an Internet stream socket) and Sprout (which Salsify's
transport protocol is based on).

The bottom line is that TCP CUBIC is actually pretty bad for reasonable-length
flows, and Sprout is empirically better (at the cost of getting a lot less
throughput!).

See, e.g.,
[http://pantheon.stanford.edu/result/1997/](http://pantheon.stanford.edu/result/1997/)
and [https://s3.amazonaws.com/stanford-pantheon/real-
world/Stanfo...](https://s3.amazonaws.com/stanford-pantheon/real-
world/Stanford/reports/2018-03-20T09-24-AWS-California-1-to-Stanford-
ppp0-3-runs-3-flows-pantheon-report.pdf)

I guess one key thing to note here is that Salsify is not a "high-bandwidth"
transport -- one of the main goals is to wait until the network is ready for a
frame (killing off encoder outputs if necessary) to avoid overloading the
network and provoking packet loss or queueing delay.

Video over RTP can mean a lot of things, including totally unresponsive
traffic that doesn't vary the sending rate in response to congestion signals
at all. If an app does this, yeah, life can suck.

~~~
aidenn0
I just remember going through a log and seeing 3 RTP streams that had gotten
into sort of a harmonic oscillation pattern where they each would observe
congestion at different times and back off in turn, and then one stream would
consume most of the bandwidth until it's backoff triggered, then another
stream would do the same.

I have zero more detail on how they were managing backoff though as this was
like 6 years ago with some random video-meeting software that probably doesn't
exist anymore (I think there were 100s of video meeting companies that started
and died from 2010-2013).

------
adam_gyroscope
This is great. I used to work on on both the traffic/network side of YT and
the encoding side, and could see the value of this approach handled by
distribution nodes at the edge of a network.

------
drewm1980
It's implemented in C++, so I guess the authors are referring to pure
functional style. I suppose they take and return encoder state as function
arguments, rather than hiding it in a class and mutating it.

~~~
Scaevolus
Yes.

> Salsify uses a purely functional video codec to achieve this. Our video
> codec is 100% conformant with the Google VP8 format, but has one major
> trick: the encode and decode functions are purely functional, with no side
> effects, and represent the inter-frame “state” of the decoder explicitly.
> This allows Salsify to make the encoder compress a frame relative to an
> arbitrary decoder state, allowing the application to safely skip frames on
> output from the encoder, not just on input.

------
krn94
interesting idea, this is a topic i'm well acquainted with. curious if the
authors have any thoughts on how this would extend to multiple encoding
sources behind the same network interface

------
marnett
At all related to Salsify the company? [1]

[1] [https://www.salsify.com/](https://www.salsify.com/)

~~~
sadjad
Not at all, just a coincidence!

------
bitrazor123
We don;t have enough CATs . We need to make them breed fast for unique
contents

~~~
quantized1
Will crypto-kitties work?

