Subject: Re: [rmcat] draft-singh-rmcat-adaptive-fec-00

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 7 Jul 2014 06:27:37 +0000

Hi

Comments inline

Regards
Ingemar

From: Varun Singh [mailto:[email-masked]]
Sent: den 7 juli 2014 00:22
To: Ingemar Johansson S
Cc: Nagy Marcin; rmcat WG ([email-masked])
Subject: Re: Re : draft-singh-rmcat-adaptive-fec-00

Hi Ingemar,

Thank you for reading the proposal and the feedback. Comments inline.

Cheers,
Varun.
---
http://www.netlab.tkk.fi/~varun
On 7 Jul 2014 00:54, Ingemar Johansson S <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi
>
>
>
> A few comments to section 3.4 and on how I believe FEC can work with SCReAM.
>
>
>
> First of all it would be necessary to add also the payload type info in the feedback messages, this to be able to distinguish between ACK of the normal RTP packets and ACK of the FEC RTP packets. This should make it possible to properly determine the number of bytes in flight and keep the ACK clocking

I need to look at scream proposal in a bit more detail to see if the increase in window and addition of FEC can be intertwined. Any suggestions or feedback on how it could work?

[IJ] If one look at figure 3 in your draft. To make it work with SCReAM I would put the RTP queue below the FEC module. The rate control measures the queuing delay in the RTP queue. If FEC packets are inserted into the queue and the transmission path is congested then there will be less room for the normal RTP packets, the effect is then that the RTP queue will build up with the consequence that the encoder bitrate is reduced. Thus, the more FEC you add, the more the bitrate is reduced to fit in the available channel capacity.. This probably requires some experimentation to verify (seeing is believing..)

> running. A second requirement is that the feedback reports must report the sequence numbers of received RTP (i.e before FEC has done its magic)
>
>

For reports we have used run length-encoded (RLE) reporting of loss (rfc3611) and discards (due to late arrival, rfc7097). These gives the pattern of losses and discards, additionally there is the post-loss repair. Combining these reports can get that information. These typically report over begin_seq and end_seq, which can be since the last RR.

If overhead is an issue, there are corresponding XR blocks that report counts of packets lost/discarded/post-repair  in an interval that can be used instead of the RLE reports, which may be more appropriate.

[IJ] Yes, it is an option to use RFC3611 also in SCReAM, I skipped it for a more simple 32bit vector loss vector however.

>
> On the sender side the FEC RTP packets are added to the send buffer just like the normal RTP packets.
>

In our implementation, we inserted them in the interval between two video frames. The pacing buffer could shape it further. However dropping FEC from the send buffer may probably require some interaction with the FEC module (for book keeping and changing the internal state).

[IJ] Sounds reasonable and should be doable with SCReAM, have not though about this too much though but it should be fairly easy to just add FEC frames, the built in rate control will then adjust the encoder bitrate depending on the amount of FEC.

>
>
> Once this is in place the detailed packet loss info in SCReAM will help the adaptive FEC framework to select the appropriate level of FEC.
>
>
>
> /Ingemar
>
>
>
> =================================
>
> Ingemar Johansson  M.Sc.
>
> Senior Researcher
>
>
>
> Ericsson AB
>
> Wireless Access Networks
>
> Labratoriegränd 11
>
> 971 28, Luleå, Sweden
>
> Phone +46-1071 43042
>
> SMS/MMS +46-73 078 3289
>
> [email-masked]<mailto:[email-masked]>
>
> www.ericsson.com<http://www.ericsson.com>
>
>
>
> “The difference between stupidity and
>
> genius is that genius has its limits."
> Albert Einstein
> =================================
>
>
>
>