[R-C] Feedback mechanisms

Wed Aug 15 15:36:42 CEST 2012

What you're bringing up is interesting, and I agree that it would be
beneficial if we had some way for the sender to ask for more detailed
feedback from the receiver. Even a fairly short-term average of
inter-arrival times isn't enough in all situations. First the averaging
interval is likely important for the sender, and if the sender is very
clever the actual timing of each of its probing packets may be important.
It's important to note though that such feedback is not as time critical as
congestion signals, and therefore several probe ACKs can be accumulated in
one RTCP.

It is of course possible to do the same computation at the receiver, but
that requires the probing method to be predefined, which is a disadvantage.

/Stefan

On Wed, Aug 15, 2012 at 2:43 PM, Bill Ver Steeg (versteb) <versteb at cisco.com
> wrote:

> 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
>
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120815/b64631b2/attachment-0001.html>