Hi all,
This is a "chair hat taken off and thrown into a corner" message -
very much my personal thoughts, and I'm very curious what you all think:
Starting point: there is a desire to have priorities between flows,
e.g. in rtcweb, but maybe also between other RTP streams.
I have been arguing that the right way to do this is to have only a
single congestion control entity, and then realize fairness among the
flows as a result of scheduling data across them. I still believe that
this is the right way to do it (and - Randell please correct me if I'm
wrong - it seems that this is the approach already pursued by
Mozilla). This thinking led me to propose my all-over-SCTP idea.
Now, I don't see how such a thing could be standardized, especially if
we don't want to limit ourselves to rtcweb only. HOWEVER: it is clear
that flows will need information about other flows - such as: what is
their priority? How many are there, that we can assume to traverse the
same bottleneck (e.g. because they share the same UDP 5-tuple)? What
is their current sending rate?
Without having agreed on how to exchange such information, I think it
will be hard to implement the above fairness solution or any other
good(*) solution in a standard-conformant way. Therefore I propose
that we should standardize what I think is the simplest possible,
necessary element: a "Flow State Exchange" (FSE).
An FSE is a *passive* entity on a host that receives congestion-
control-relevant information from RTP flows and provides that
information upon request. It resides on a host, and if we define it in
the right way it probably doesn't matter at which layer: one could
have an FSE inside the browser, and optionally have the browser talk
to an additional system-wide FSE in the kernel. Note that this is not
the Congestion Manager (RFC3124): the CM was an *active* entity, much
more complicated to realize, and much closer to the "single congestion
control instance" idea described above.
With an FSE, a single congestion control instance could be realized as
follows:
RTP flows => update the FSE.
CC. instance => reads information from the FSE, then controls the
sending rate per RTP flow and schedules data across the flows.
Alternative implementation (not as good, but simpler, and just to show
the flexibility): RTP 1 uses its own CC, RTP 2 uses its own CC, but
they feed the priority they got "from above" into the FSE and read
each other's priority and total sending rate from there, to adapt
their increase/decrease behavior accordingly, leading to the desired
total behavior on the wire.
It's not hard to imagine that this could be extended in many ways -
e.g. the SCTP data channel could access the FSE to also incorporate
priorities there... and implementations could provide information
about which flows share a bottleneck based on measurements, not only
because of the UDP 5-tuple, without requiring to standardize any of
that. But the FSE itself would have to be there.
What do you all think?
Cheers,
Michael
-----------------------
(*) The only prioritization solution that I can think of which would
not require something along the lines of an FSE would be prioritized
congestion control, i.e. giving weights to something like MulTCP,
MulTFRC ... which means that the fairness you get is essentially
what flows produce, as the result of fighting it out on the
bottleneck. This will create more delay than any FSE-based solution,
working against one main goal of all of us here: reduced delay.
