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

[Karen Elisabeth Egede Nielsen <[e-mail]>]

Just one comment to this realm:

In some application domains (e.g., signaling environment) TCP is running
bi-directional steady.
One thing to note is that the run of data with SACK  (SACK is feedback
path) actually gives additional robustness to drop
of feedback as data retransmission algorithms help recover cc feedback
information.

I don't know how the RTP feedback is designed and whether the above
comment is relevant in this context, but
thought that I would give it anyway.

BR, Karen

> -----Original Message-----
> From: rmcat [mailto:[e-mail]] On Behalf Of Xiaoqing Zhu
> (xiaoqzhu)
> Sent: 7. november 2015 05:34
> To: Randell Jesup <[e-mail]>
> Cc: rmcat WG <[e-mail]>
> Subject: Re: [rmcat] How we should handle feedback, and where the
> congestion should run
>
> 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
> >