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

[Jim Gettys]

On 09/24/2012 10:46 AM, Harald Alvestrand wrote:
> On 09/19/2012 02:26 PM, Michael Welzl 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.
>>
>> 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.
> I don't see the logic here. The requirement is that both sides send
> signals that are responded to appropriately by the other side. So the
> two sides' mechanisms have to be compatible (in the RRTCC case, the
> demand is that the sender responds to REMB or TMMBR messages - this is
> hardly the "same mechanism" as the Kalman filter implemented on the
> receiver side).
>
> In the TCP case, the feedback mechanism is the ack, which is needed
> for reasons beyond congestion control. In the RTP case, there isn't
> such a single, simple mechanism needed for other reasons.
>>
>> 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.
> FSE?
> I don't see the logic here either. Either the two flows are under a
> common controller on one side, they're under a common controlller on
> the other side, they're not under any common controller, or they are
> under common controllers on both sides. All four cases can happen with
> both sender side and receiver side implementations of the BWE
> computation.
>>
>>
>> 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
> Stickler: Amount of feedback has little correlation with packet drop.
> If feedback is lost due to congestion, more feedback will lead to more
> packet drops. What is true is that when feedback occurs more rarely,
> losing one feedback packet will lead to a greater gap between feedback
> packets. 

Even more fun; due to bufferbloat, combined with very asymmetric
bandwidth in many paths, the feedback packets can be greatly delayed for
reasons that have nothing to do with your transmission, which may have
plenty of bandwidth available.  So your servo loop responsiveness for
adjustment of sending bandwidth will be poor :-(.  In TCP's case, I
gather that this adjustment of transmission rate is a quadratic, so the
elephant flows that may be clogging the return path aren't going to be
responding in reasonable time.
                Sigh,
                        - Jim