[R-C] Sender- vs. receiver-based, yet again...

[Stefan Holmer]

On Wed, Sep 19, 2012 at 2:26 PM, Michael Welzl <michawe at ifi.uio.no> wrote:

> Hi,
>
> Sorry for bringing this up yet again - but my thoughts just keep returning
> to the question of sender-vs.-receiver based congestion control, because
> it's a seemingly simple problem for which we should be able to agree on a
> clear answer?!
>
> As most of you probably know by now, I'm critical of a receiver-based
> approach as in RRTCC. (In fact, as I will explain further below, I argue
> against a *combined* sender+receiver approach). Here is a plus/minus list
> as I see it:
>
>
> PLUS no. 1: it helps to reduce the amount of feedback. That's really the
> ONLY benefit.
>

It also has a small benefit in that it can more easily make use of new
signals as they are introduced, without having to modify the feedback
message, but I guess that argument is a bit hypothetical.


>
> MINUS no. 1: it requires the same mechanism on the sender and receiver
> side, which means that, if RTP becomes a "framework" for congestion control
> mechanisms, we must signal which mechanism is used to the other side. In
> contrast, we don't have to do this with TCP's (implemented but not
> standardized) pluggable congestion control. This is, to me, the biggest
> problem, as it requires code updates to happen on both sides for a new
> mechanism to be deployed.
>
> MINUS no. 2: it could make combined congestion control between multiple
> flows via the FSE more complicated. Anyway it seems we'll need an FSE on
> the sender AND receiver side, but with receiver-based congestion control,
> we'll face the question: for two flows between the same two hosts, sharing
> the same bottleneck, should the receivers exchange information and
> coordinate their feedback, or should the senders exchange information and
> coordinate their behavior?  => when congestion control mechanisms are split
> across sender and receiver, the right answer to this question becomes a
> per-mechanism decision.
>
>
> Please amend this list if I'm missing something. Regarding the one PLUS
> above, here's a critical look at the benefits of reducing feedback **via
> receiver-side congestion control**:
>
> - less feedback means a greater chance for the feedback to be dropped,
> which translates into a greater chance for undesirable sender behavior
> - we deal with interactive traffic, in which case a lot of the feedback
> could hopefully be piggybacked onto payload packets
> - in some cases there will be other parallel flows (e.g. the data channel
> in rtcweb) that already give us all the feedback that we need, this is
> another chance for feedback reduction
> - receiver-side-congestion-control-based feedback reduction as in RRTCC
> means to reduce the feedback whenever feedback isn't urgent for the sender.
> I'd argue that, in fact, we should reduce feedback only when the channel
> carrying it (the backwards channel) is congested, and that is a generic
> function, not bound to the sender-side congestion control behavior.
>
>
> So how urgent is it to reduce feedback, anyway? Some time ago, Bill Ver
> Steeg wrote:
>
> ***
> 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.
> ***
>
> As he states, multicast is out of scope. Plus, I think we should care more
> about technical reasons than what the RTP community considers to be a
> precious resource. As for the CableTV example, one can always find examples
> where people started doing useless things  :-)   but consider the
> following: many parallel TCP connections, each sending lots of feedback,
> work okay for maaaany end users that 1) surf the Internet or (bringing it
> closer to rtcweb thinking)  2) use P2P applications. And TCP doesn't even
> do any form of congestion control on ACKs (an RFC exists but noone uses it
> (so far)).
>
> I'm not saying ACKs never cause problems. I'm saying it's probably rare
> that they do, and reducing their number WHEN they cause trouble is good
> enough (and, I would argue, a better decision).
>
>
> Let's take a step back and summarize the situation:
> 1) congestion-control-based-feedback-reduction has at least one
> significant MINUS (no. 1), probably two
> 2) the benefits of doing it seem minimal
> 3) not being based on congestion along the backwards path, it misses the
> point somewhat...
>
>
> As a result of the above, I would suggest to move all congestion control
> functionality to the sender side and keep the receiver side dumb, as in
> TCP, but amended with some generic (i.e. not mechanism-specific)
> feedback-reduction functions (ACK congestion control; piggybacking;
> omitting feedback when it is known (e.g. via a signal from the sender) that
> we get feedback from another flow).
>
> Alternatively, we could still remove the MINUS no. 1 above by agreeing on
> a generic sender behavior. IIRC, in RRTCC, the sender is rather simple - it
> follows the rate dictated by the receiver and has a timeout behavior. If
> all congestion control mechanisms are installed on the receiver side only,
> with the same agreed generic sender behavior for everyone, we can also have
> pluggable congestion control without a need for signalling.
>

I agree that if we go for a receiver-based approach, the sender must be
dumb. And the other way around if we go for a sender-based approach.


>
> It's just the idea of multiple proposals for congestion control involving
> newly described sender AND receiver behavior that strikes me as bad design.
>
> Thoughts?
>

One benefit I see with having the intelligence at the sender is if you want
to do something more clever when probing the channel, which would require
coordination between the sender and the one who's supposed to come to some
conclusion from the incoming packets. I think Bill Ver Steeg touched upon
something along those lines:

"Basic senders will simply tell the receiver to gather the data every N
seconds and send it every N seconds (plus when there are problems, as
defined by the specification). More sophisticated senders could drive more
complex relationships, asking the receiver to tabulate/send the data on
demand in semi-real time. This would allow a sophisticated sender to send a
varying data patterns and get the feedback they require, yet not require
too much shared state between the sender and receiver. As long as the
receiver is a simple state machine, I think we would be OK."


>
> Cheers,
> Michael
>
> _______________________________________________
> 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/20120921/74f8a60a/attachment.html>