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

[Ingemar Johansson S <[e-mail]>]

Hi
First I think that there biggest reason to have congestion control on either sender "XOR" receiver side is that it removes some of the issues with synchronization between sender and receiver (as pointed out by Stefan). It is for instance quite likely that some users update their browsers on a regular basis, while others do it less often. This of course means that one need to make the feedback generic and as future proof as possible. draft-holmer-rmcat-transport-wide-cc-extensions is a very good start in that direction, one can always argue on the details and an AVT approved version will probably look different, but for experimental purposes I welcome the generic feedback draft and hopefully we will have it implemented in OpenWebRTC before the next IETF meeting.

Sender XOR receiver (a +1 on Stefan´s and John´s comment below)
It is no secret that I favor sender side rate adaptation, in fact I find it hard to understand how SCReAM would be implemented on the receiver side. 
To take one example, the stream prioritization in SCReAM is quite straightforward, and that is because of the sender side implementation, for instance in the cases where the throughput drops and the video coder rate reduction lags behind, the stream prioritization can prioritize a smaller audio stream and enable audio without (too noticeable) interruptions, even though video freezes.  There are also a few necessities with video such as FIR that can potentially bloat a network bottleneck, the sender side algorithm here has a better capability to decide when and how to send the packets with the objective to reach the best possible aggregate media quality.

/Ingemar

> -----Original Message-----
> From: John Leslie [mailto:[e-mail]]
> Sent: den 9 november 2015 18:23
> To: Stefan Holmer
> Cc: Randell Jesup; rmcat WG; Michael Welzl
> Subject: Re: [rmcat] How we should handle feedback, and where the
> congestion should run
> 
> Stefan Holmer <[e-mail]> wrote:
> >...
> >
> > Another thing that the receiver doesn't know, is if the sender decided
> > to send the packets in some particular pattern to probe the link. It
> > can try to infer the packet based on the send-time extension, but it's
> > much easier to do at the sender where you actually know what you tried to
> do.
> 
>    +1
> 
>    There are a number of tricks available here, the sender serving different
> levels of time-sensitivity. Also, the sender has the best idea of RTT, and may
> wish to hold a sending rate constant _only_ for the portion of the RTT which
> is likely to hit a congested forwarder (for a particular packet) -- in order to
> optimize the reduction-to-sending-rate-when-the-packet-was-sent.
> 
>    (I am happy to have receiver-side experiments along with sender-side
> experiments: I just have a strong prejudice about which will win. ;^)
> 
> --
> John Leslie <[e-mail]>
>