[rmcat] How we should handle feedback, and where the congestion should run

[Randell Jesup <[e-mail]>]

The line in the room was cut, but a few comments:

Even if RMCAT yields a single algorithm, having a standardized feedback 
message will help future work to improve on the algorithm, or to develop 
or deploy future algorithms.  This will not be the last work done in 
this area, and I'm sure improvements will be worked on, and people will 
trial alternative algorithms.  Getting support for the "other end" is a 
huge step forward in trialing (or deploying) an algorithm.

Also it appears there are multiple implementers dealing with the 
bandwidth and frequency for RTCP traffic if the control is on the sender 
side.  Almost all algorithms *can* be moved to run entirely on one side 
or on the other.  Running it on the receiver side can dramatically 
reduce the feedback required (as Michael said in the room).  Given use 
of the RTP send-time header extension, there's very little info that the 
sender has that the receiver doesn't (mostly just the size and timing of 
any lost packets).  The bandwidth for sending CC results would be far 
less than any (compressed or not) arrival time feedback to the sender.

Running on the receiver also means that no "merging" of feedback data 
needs to be done to run CC across multiple streams/5-tuples/etc.

We can build a generic arrival-time feedback message, or we can build a 
generic results-of-receiver-CC message.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email [e-mail]!  Way too much spam