[R-C] Feedback mechanisms

[Bill Ver Steeg (versteb)]

Piers-

This is somewhat true. For the general cases, there will be AV data flowing in both directions. 

However, for a significant portion of the time, the use cases will be driven by the available BW and quite asymmetric. For instance, if a remote worker is having a conference with somebody in a traditional office, the downstream flows may be HD and the upstream flow may be a thumbnail, or even just voice. Another common case is a multi-party conference in which there are N downstream AV flows and just 1 upstream AV flow. If we were to ack every packet, the upstream acks of the downstream flows could actually consume more BW than the upstream audio/video flows.

Some simple math follows for a worst case scenario (note that I am not recommending we do this, as it is simply the wrong way to proceed)- Downstream flow D = 6 Mbps ~= 500 packets/sec. If we were to do something onerous and ack every packet with 50 bytes of data, that would be ~200 Kbps upstream. We can play games with ack sizes and piggybacking acks on data, but IMHO a per-packet ack is simply not the right way to start the design.


bvs


-----Original Message-----
From: Piers O'Hanlon [mailto:p.ohanlon at gmail.com] 
Sent: Wednesday, August 15, 2012 7:08 AM
To: Bill Ver Steeg (versteb)
Cc: Mo Zanaty (mzanaty); Michael Welzl (michawe at ifi.uio.no); Randell Jesup; rtp-congestion at alvestrand.no
Subject: Re: [R-C] Feedback mechanisms

Hi Bill,

In reference to point your (1) - I'd have thought the RMCAT flows would differ from streaming/TCP community as they are generally going to be sending flows in both directions simultaneously so we're often (with ADSL, Cable) going to be limited by that upstream capacity for actually sending media in most cases - so the sender's [b]ack-channel is going to be using the 'downstream' channel which won't be limiting feedback much.

Piers

On 14 Aug 2012, at 15:33, 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.
> 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 suggest that we think along the lines of a message that conveys something like " I got N1 packets over T1 time with L1 loss and D1 delay and J1 jitter, then N2 packets over T2 time with L2 loss and D2 delay and J2 jitter, yada, yada, yada". In the simplest case, there is constant delay and no drop, and the packet is infrequently sent. In the more complex cases, a more verbose packet is sent - probably at a more frequent interval. 
> 
> If we have a way for the sender to define the grouping of these semantics, it COULD send a series of shaped bursts that probe the network. For instance, it could send large packets at a certain rate for the steady state, then occasionally send back-to-back packets to probe for additional BW (this is the hard part of any rate adaptive algorithm....). It does not need the timing of every packet, but if it can define the feedback summary intervals, a sophisticated sender could do some pretty advanced things. A simple sender could choose to do simple things.
> 
> Note that the time intervals can overlap between successive feedback reports, thus providing some protection against loss of feedback packets.
> 
> Also note that we need to be crisp in our definition of these "delay", "jitter", etc in such summarized report. Are they max, min, average, mean? For the purposes of this email, I gloss over this detail, but it is important and will need to be addressed
> 
> Bill VerSteeg
> 
> -----Original Message-----
> From: rtp-congestion-bounces at alvestrand.no [mailto:rtp-congestion-bounces at alvestrand.no] On Behalf Of Mo Zanaty (mzanaty)
> Sent: Saturday, August 11, 2012 6:51 PM
> To: Michael Welzl (michawe at ifi.uio.no); Randell Jesup; rtp-congestion at alvestrand.no
> Subject: Re: [R-C] Feedback mechanisms
> 
> Michael Welzl <michawe at ifi.uio.no> wrote:
>> ...piggybacking ACKs on RTP payload...
> 
> Randell Jesup <randell-ietf at 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.
> 
> 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.
> 
> 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.
> 
> Mo
> 
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion