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