Re: [rmcat] How we should handle feedback, and where the congestion should run

["Xiaoqing Zhu (xiaoqzhu)" <[e-mail]>]

Hi Randell, 

I noticed your mention of ³Š I don't think they've even really gotten much
into two-way tests; all the graphs I see are for one-way. Two-way will
complicate things - and it's a critical part of the use-cases.²  Fully
agree on the importance of two-way calls as use cases.

In the eval-test-case draft, there is currently one test case dedicated
for exploring impact of two-way traffic (Sec. 5.3.  Congested Feedback
Link with Bi-directional RMCAT flows). Some corresponding graphs can be
found below (they may not reflect the most up-to-date algorithm
performance). 

* NADA:http://www.ietf.org/proceedings/92/slides/slides-92-rmcat-4.pdf
(page #9 and #10)
* SCReAM: 
http://www.ietf.org/proceedings/interim/2014/11/09/rmcat/slides/slides-inte
rim-2014-rmcat-1-1.pdf (page #9)
(Sorry, I was not able to find one with GCC yet.).
  
Would like to know whether you think that current design of the test case
has captured gist of the issue encountered by two-way calls, or any
suggestions on additional test scenarios in that regard?

Thanks,
Xiaoqing



On 11/6/15, 8:09 AM, "rmcat on behalf of Randell Jesup"
<[e-mail] on behalf of [e-mail]> wrote:

>On 11/6/2015 2:52 AM, Michael Welzl wrote:
>> The big problem I see with receiver-side schemes is that you don't only
>>need to standardize 1) the feedback message, you also need to
>>standardize the sender behavior in the absence of feedback.
>> 2) If feedback is missing for a while, maybe that's a good thing, as a
>>result of feedback suppression?  So we just gradually and blindly
>>increase the rate?  See early versions of the GCC scheme.
>> 3) If feedback is missing for a long time, at some point you HAVE to
>>have a timeout and react accordingly.
>>
>> Can we agree on all these things? At least 1) AND 3) are necessary.
>
>I agree that we'd need to standardize that when using a receiver-side
>algorithm with a generic message (i.e. not a matched sender with a
>custom/private message), the sender side must be prepared to deal with
>1) and 3) and likely 2), and we would need to specify fairly completely
>the sender-side behavior in response to the feedback (though that
>behavior can be simple).  I.e. the send will attempt to send at the rate
>requested in a feedback message; will inform codecs of the new rate as
>fast as possible; will optionally pace data entering the network to not
>exceed either the congestion rate, or a separate pacing rate supplied.
>Time periods for calculating both rates shall also be provided, though
>the sender may not be able to use an arbitrary time for calculating rate
>(i.e. encoders may not be flexible on that - easier to do for pacing).
>
>In terms of 1/2/3 above: if we do this, the receive-side algorithm could
>configure the sender via these messages and/or negotiation. The feedback
>messages can (optionally) have control information that tells the sender
>what to do on missing feedback, and when.  For example, it could have a
>feedback-timeout field, or timeout and what-to-do-at-timeout fields.  We
>could also define a "are you still there" RTCP that can be sent when we
>see feedback timeouts or are getting close to them, asking the receiver
>to resend (and exactly how to respond to those can be part of the
>receive-side CC algorithm).  It could include updated RS/RR stats for
>any RTP flows, letting the receiver-side update their idea of the
>return-path congestion.
>
>This brings up a more general point for coupling congestion control (I
>forget if this has been discussed) - not only can it make sense to
>couple multiple CC's running in the same direction, but also to inform
>CC's of return-path congestion (and expected network delay!) that
>feedback (RTCP) will contend with.  This applies no matter which end the
>algorithms run at.
>
>I'm sure more specification of a standard receive-side feedback message
>would needed if we decide to go that way; the above would be a start.  I
>do think it's *very* worthwhile defining a standard for feedback
>(whichever end we end up with) such that new single-ended algorithms can
>be trialed or deployed (and coincidentally provides a way for the CC
>algorithm to probe to see if the other side supports something
>compatible, without mandating it be part of a higher-level negotiation).
>
>> To me, this seems like creating difficulties for a problem that MAY
>>also be a non-problem. Note that TCP sends tons of feedback, maybe
>>including SACK blocks, across the same thin uplinks that we're
>>considering. I don't think there is conclusive evidence of that being a
>>problem.
>
>True - but the constraints on TCP are very different, forward delay is
>encouraged to maximize throughput, traffic is often primarily
>unidirectional (so the feedback path is uncontended and often close to
>loss-free especially where the bottleneck link is the local last-mile or
>Wifi), while for us we typically have saturated links in both directions
>while trying to keep delays low, and each packet of feedback takes away
>from payload.
>
>> => I tend to think that moving everything to the sender side is an easy
>>way out.
>
>This still may be so, since in many ways (see above) it's easier to
>feedback raw data and keep *all* decisions at the sender side. (Though a
>sender-side standard feedback packet may still need rules on how to
>operate in reverse-path contention/loss that will need to be added.)
>However, as several of the candidates mentioned, there are issues with
>reverse-path bandwidth use - and I don't think they've even really
>gotten much into two-way tests; all the graphs I see are for one-way.
>Two-way will complicate things - and it's a critical part of the
>use-cases.
>
>A send-side setup with feedback from the receiver for each packet
>(generic or not!) will almost certainly require careful compression
>decisions (and feedback-rate decisions, perhaps semi-controlled by the
>sender - see above similar to the receive-side discussion).  For this
>reason alone, I'm not sure if RTCP-XR will work, even with modifications
>or additions - but I haven't looked much at RTCP-XR other than to note
>it has a LOT of stuff and isn't very thin.  But take that with a grain
>of salt.
>
>-- 
>Randell Jesup -- rjesup a t mozilla d o t com
>Please please please don't email [e-mail]!  Way too much
>spam
>