On 08/13/2012 10:34 AM, Michael Welzl wrote:
Hm, hm, hm. I'm not sure about that, either.
Let me try to sketch what I think would be good design and see what you people say - if there is a chance to get something like that to actually work:
First of all, I think that, to keep queues low, the sender needs as much feedback as it can possibly get. Say, one ACK for every packet. The amount of that feedback can be too much, but then the right thing to do would be to use some form of ACK congestion control, to reduce the amount of this feedback *only* when needed but generally send as much as possible. There are working methods for doing that, and they're not too complicated. I've already opted out at this point. The algorithm needs all the information it can get, but the idea that the algorithm is only executed at the sender is something I don't see as a given.
Data reduction at the receiver and considering the feedback volume / result tradeoff is not unusual.
Clearly, since we're talking about a lot of feedback here, these packets should be as small as possible. Maybe there are forms of RTP/RTCP header compression that we could use for that? Or, do we really need to even require a RTP/RTCP header for them?
The content of these packets is general congestion control relevant feedback about the path - we know quite well from experience what sort of information should go in them: not much more than a sequence number, and possibly a timer. Anyway, I think it's clear that this can be generically designed.
Secondly, I think that mechanism-specific RTCP feedback is welcome and necessary, for higher-level optimizations (giving information to codecs that they should react upon). Maybe also for more - but these could be larger packets, and sent much less frequently.
Now I wonder: are these very small high frequency ACK packets just a designer's dream, or are they something that could possibly be made to work in some way?
Cheers, Michael
On 13. aug. 2012, at 10:12, Colin Perkins wrote:
Maybe I wasn't clear. I wasn't saying limit the feedback; rather let's not worry about optimising transport of the feedback until we know what feedback we want.
Colin
On 13 Aug 2012, at 10:28, Michael Welzl wrote:
Hm, I think I don't agree with considering such optimizations later: the way I read the charter, we're providing a framework for cc. algorithms, i.e. *the* algorithm doesn't exist.
It's not hard to construct cases where limiting feedback may be a bad idea. For example: the queue grows => before the sender can notice it or react, you lose just the few feedback packets that are sent, the sender has to resort to a timeout => even more queue growth due to slow reaction; this may seem a bit artificial, but do we already want to make a decision to live with this situation?
If decisions follow the sequence: 1) first algorithm: has limited feedback 2) define feedback just for that algorithm, assume it works for all 3) more algorithms...
... then we may be putting ourselves in a corner that we can't get out of, making it impossible to define a mechanism that would solve problems like the one above.
Cheers, Michael
On 13. aug. 2012, at 07:00, Colin Perkins wrote:
It might be more productive to consider this sort of optimisation later, once we've defined the congestion control algorithm, and seen if it's needed. Optimising the header overheads on a not-yet-defined protocol seems premature, and it's not clear that we need enough feedback to require this sort of optimisation.
Colin
On 13 Aug 2012, at 02:03, Harald Alvestrand wrote:
Is there value in going completely extreme and define a generic header extension for piggybacking RTCP in RTP packets?
That way, whatever we define in RTCP can also be carried as a header extension, if it makes sense to do so.
Of course, it may rarely make sense.
On 08/12/2012 06:26 AM, Randell Jesup wrote:
On 8/11/2012 6:50 PM, Mo Zanaty (mzanaty) wrote: > Michael Welzl <michawe@ifi.uio.no> wrote: >> ...piggybacking ACKs on RTP payload... > Randell Jesup <randell-ietf@jesup.org> wrote: >> ...use header extensions as an alternate channel for RTCP... > Several implementations do either or both of these things, in proprietary ways obviously. I think both should be standardized, although this may be an unpopular view in AVT. I *may* agree, though I also agree it may be unpopular.
I've had to do it because of using SBCs configured not to pass RTCP at all and didn't like RTCP on the RTP port, and I needed it for PLI/etc. But that was a rare homegrown (though ISP-wide) SBC; even misconfigured SBCs typically support RTCP-mux I imagine. And I did it before RTCP-mux was defined, and was part of why I supported RTCP-mux.
Once you start pushing enough data to double the normal packet rate, the per-packet overhead can get to be a problem, especially if you're on a low-bandwidth link. Instead of (say) 30 video + 50 audio packets per second, you have an additional 80. Sending them in header extensions would save around 20Kbps, perhaps a little more - marginal if you have 250Kbps or up, but significant if you have (say) 128Kbps, and already are losing around 25Kbps to overhead. My old phones would run 30fps down to total bandwidth of as low as 60-80kbps, though it was running QCIF down that low (plus iLBC 20ms - 15Kbps+overhead, so video payload got as low as 40, even 30Kbps). At those bitrates, 20Kbps is huge.
I'll admit given RTCP-mux (and assuming nothing interferes with negotiation of it!), the argument is largely one of efficiency in bandwidth and packet-rate. And this is much less of an issue if you're not sending circa 1 feedback message per packet.
I assume this would fall in CORE.
> Note that there is no standardized generic ACK. I just submitted an errata to the RFC 4585 ABNF to clarify that "ack" (without parameters) is invalid since there is no generic ACK. There is only "ack rpsi" which is specific to H.263 Annex N, and "ack app" which is proprietary. I think there was a generic ACK in an earlier draft, but it was removed (I think a hole in the code list was left to avoid breaking people working with the draft).
> Beyond ACK, many other types of RTCP feedback would benefit from the efficiency of piggybacking in RTP header extensions. (NACK, ECN, FIR, TMMBR, PLI, SLI, etc.) So a general mechanism for all RTCP feedback may be more useful than a single mechanism for ACKs. Quite true. The toughest part is to define when such a thing should be used over RTCP-mux. It would make using other header extensions tricky (though possible), and it would imply a circa up to 20, 30, perhaps in a few cases 100ms delay in sending feedback (avg circa 1/2 that; less if they can piggyback on other RTP streams). If there's "important" data you could send a direct RTCP and not wait.
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Colin Perkins http://csperkins.org/