From: "Xiaoqing Zhu (xiaoqzhu)" <xiaoqzhu@cisco.com>
To: Randell Jesup <randell-ietf@jesup.org>
Thread-Topic: [rmcat] How we should handle feedback, and where the congestion
 should run
Thread-Index: AQHRGGgZ8Hg3ExfP+kmWpw3jKvSP2p6PjtIAgABJzAA=
Date: Sat, 7 Nov 2015 04:33:44 +0000
Message-ID: <D262BB29.29148%xiaoqzhu@cisco.com>
References: <563BF7C3.40500@jesup.org>
 <2CEE6E71-BCDC-4778-88D1-8EDE87BAAE4D@ifi.uio.no>
 <563CD0BE.1010807@jesup.org>
In-Reply-To: <563CD0BE.1010807@jesup.org>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.96.145]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <BA06E731F94BD743A183D30F43E5DC62@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rmcat/ejFFaTHIghwblcrNkq6ja1qQsZk>
Cc: rmcat WG <rmcat@ietf.org>
Subject: Re: [rmcat] How we should handle feedback,
 and where the congestion should run
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group
 discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>,
 <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>,
 <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Nov 2015 04:33:48 -0000

Hi Randell,=20

I noticed your mention of =B3=8A I don't think they've even really gotten m=
uch
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.=B2  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).=20

* NADA:http://www.ietf.org/proceedings/92/slides/slides-92-rmcat-4.pdf
(page #9 and #10)
* SCReAM:=20
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.).
 =20
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"
<rmcat-bounces@ietf.org on behalf of randell-ietf@jesup.org> 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.
>
>> =3D> I tend to think that moving everything to the sender side is an eas=
y
>>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.
>
>--=20
>Randell Jesup -- rjesup a t mozilla d o t com
>Please please please don't email randell-ietf@jesup.org!  Way too much
>spam
>