[R-C] Feedback mechanisms

[Michael Welzl]

On Aug 14, 2012, at 4:33 PM, Bill Ver Steeg (versteb) wrote:

> I also like the direction this is heading. A few detailed comments-
>
> There are two competing requirements -
> 1- The upstream/return traffic is (generally) assumed to be a  
> precious resource by the RTP community. This is partially due to  
> multicast considerations (which we can mostly ignore here) and  
> partially due to asynchronous networks. Note that the CableTV  
> community has found it necessary to play games with TCP acks in  
> Cable Modems because of upstream bandwidth limitations, even for  
> unicast TCP traffic. This is an ugly hack that I will not defend  
> here, but it is indicative of the problem space. The net-net is that  
> we have to be somewhat conservative in our sending of acks, or we  
> will end up in similar trouble.

But there's a solution for that: ACK congestion control (RFC5690 for  
TCP, not really used up to now, and a part of DCCP)


> 2- The receiver/sender would like to be able to get enough  
> information about loss and delay to sense congestion. In the RTP  
> case, the receiver knows the one-way delay and loss rate every time  
> it gets a packet. In an overly-simple model, the receiver would just  
> ack very single packet with a short packet (containing the a summary  
> of the last few packets to protect against loss), and the sender  
> would then know all of the gory details of the downstream delay/loss  
> and the upstream delay/loss. This is clearly overkill.
>
> So, our challenge is to design a feedback mechanism that is timely  
> and information rich, yet does not break the bandwidth budget.


I like Stefan's statement, which - I think - fits in that context:

> Worth noting that we have the option of only sending frequent feedback
> (e.g. once per packet) when we experience congestion. The rest of  
> the time
> we can simply trigger the feedback periodically.

Cheers,
Michael