Subject: Re: [payload] FLEXFEC: retransmissions optimization

From: Magnus Westerlund <[email-masked]>
Date: Thu, 1 Sep 2016 15:28:22 +0200

Den 2016-08-23 kl. 13:48, skrev Stefan Holmer:
>
>
> On Thu, Aug 18, 2016 at 7:42 PM Varun Singh <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Stefan,
>
>     On Tue, Aug 16, 2016 at 2:09 PM, Stefan Holmer <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > I agree that we should have the sequence numbers in the flex fec
>     header, but
>     > timestamps I don't see why we need there. RFC 4588 does the same
>     > optimization without running into problems, right?

 From my perspective RFC4588 do run into some issues due to having the 
RTP timestamp not be anything close to representing transport emission 
time. Sure, there are quite many format that has the issue that one 
can't use the RTP timestamp field for transport purposes.

But, I do note that the Retransmission format will not even be 
monotonically increasing for 4588. This is one does a second 
retransmission of an older packet next to newer packets.
>
>
> Two follow-up questions:
> 1. What RTP timestamp frequency do we recommend for flexfec packets?
> This doesn't seem to be specified in the draft.

This should be sufficiently high for transport related sampling. I would 
say 10 kHz is likely sufficient. It should definitely not be below 1kHz.

>
> 2. What value do we think the current definition of the flexfec
> timestamps will provide (representing the transmission time of the
> flexfec packet)? The possiblity of computing the trannsmission jitter?
> It's not immediately obvious to me what value that adds.

Yes, jitter calculation is one thing that is possible. But I do note 
that it is not as useful as for something that is regularly emitted. 
However, the timestamp will provide some indication on how quickly and 
when retransmission decisions was acted on. This can help determine for 
the receiver the necessary timing needed for a RTX request to reach the 
receiver. It can also provide a box in time when a missing RTX was sent, 
if the packets after and before was received. Enabling better adaptive 
handling of retransmission loss.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------