[R-C] Feedback mechanisms
Michael Welzl
michawe at ifi.uio.no
Wed Aug 15 12:10:46 CEST 2012
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
More information about the Rtp-congestion
mailing list