Re: [rmcat] Fwd: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-01.txt

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

Hi

I have experimented a bit with ack clocked algorithms for rate adaptation (in simulator). Originally I implemented it as something that required an extra layer with per packet feedback between RTP and UDP, this is briefly described in Nikolas Hermanns master thesis *
SCReAM ** is however based on RTCP feedback, in order to keep the RTCP feedback overhead limited it is recommended to use reduced size RTCP with transmission of full compund RTCP every T_rr_interval. The feedback in the current implementation transmits feedback as often as possible but it is actually AVPF regular mode transmission, I have found out that in practice I end up with one feedback roughly every video frame internal. The feedback thus resembles TCPs delay ACK mechanisms. And it seems to work fine. I suspect however that there is an increased risk that coalescing (or is it called ACK compression) effects are amplified. I will later on investigate if this a problem in reality and if Immediate mode tranmission improves things.
I would not recommend to use per frame feedback with SCReAM, a single lost packet means that an entire video frame is discarded with the effect that no feedback is transmitted (for that frame). This can make the ack-clocking to hickup, not sure if it is a serious problem but believe that the per packet feedback limited by the AVPF regular mode timing is safer.

/Ingemar

*http://www.lauritshamm.de/MediaRateAdaptationConversationalVideoServicesNextGenerationMobileNetworks_Hermanns_2013_Thesis.pdf

** http://tools.ietf.org/id/draft-johansson-rmcat-scream-cc-02.txt
> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: den 2 juli 2014 14:15
> To: rmcat WG
> Subject: [rmcat] Fwd: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-01.txt
>
> This draft discusses what congestion control feedback is achievable with
> RTCP. I presented the initial version to RMCAT at IETF 86. This version
> updates Section 3.2 based on discussion with Magnus Westerlund, to give
> more accurate recommendations on the session bandwidth needed to allow
> per-frame RTCP feedback.
>
> I don't think this needs agenda time at IETF 90, but is rather provided to
> inform the design of the congestion control feedback proposals.
>
> Colin
>
>
>
>
> Begin forwarded message:
> > From: [e-mail]<mailto:[e-mail]>
> > Subject: I-D Action: draft-perkins-rmcat-rtp-cc-feedback-01.txt
> > Date: 2 July 2014 12:50:09 BST
> > To: [e-mail]<mailto:[e-mail]>
> > Reply-To: [e-mail]<mailto:[e-mail]>
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> >
> >        Title           : Using RTP Control Protocol (RTCP) Feedback for Unicast
> Multimedia Congestion Control
> >        Author          : Colin Perkins
> >     Filename        : draft-perkins-rmcat-rtp-cc-feedback-01.txt
> >     Pages           : 8
> >     Date            : 2014-07-02
> >
> > Abstract:
> >   This memo discusses the types of congestion control feedback that it
> >   is possible to send using the RTP Control Protocol (RTCP), and their
> >   suitability of use in implementing congestion control for unicast
> >   multimedia applications.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-perkins-rmcat-rtp-cc-feedback/
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-perkins-rmcat-rtp-cc-feedback-01
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-perkins-rmcat-rtp-cc-feedback-01
>
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>