Subject: Re: [payload] FLEXFEC: retransmissions optimization

From: Stefan Holmer <[email-masked]>
Date: Tue, 16 Aug 2016 08:49:52 +0000

Sounds like good optimizations to me. Below are some, possibly naive,
suggestions:

Have we considered also reusing the timestamp field in the RTP header to
save another 4 bytes by not having the timestamp field in the flex fec
header when doing retransmits? Since the RTP timestamp should represent the
sampling instant of the first octet in the RTP data packet, it seems
reasonable that it is the original timestamp and not something newly
generated for the retransmit.

The same thing might be possible to do with PT recovery.

/Stefan

On Thu, Jul 21, 2016 at 3:26 PM Varun Singh <[email-masked]> wrote:

> Hi all,
>
> Following up on the discussion based in the Payload session at Berlin.
>
> The current draft has the following format
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |F|R| P|X|  CC   |M| PT recovery |         length recovery      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                          TS recovery                          |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   SSRCCount   |                    reserved                   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                             SSRC_i                            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |           SN base_i           |k|          Mask [0-14]        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |k|                   Mask [15-45] (optional)                   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |k|                                                             |
>        +-+                   Mask [46-108] (optional)                  |
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                     ... next in SSRC_i ...                    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> For retransmission, decomposes to (also in the draft):
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |1|1| P|X|  CC   |M| PT recovery |         length recovery      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                          TS recovery                          |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   SSRCCount=1 |                    reserved                   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                             SSRC_i                            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |           SN base_i           |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> The was called out to be suboptimal in Yokohama, and we are now suggesting
> the following:
>
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |R|F| P|X|  CC   |M| PT recovery |         sequence number      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                            timestamp                          |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                               SSRC                            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>        |                              Retx                             |
>
>                 :                                                            RTP payload                                                        :
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> Just want to call out a few things here, comparing FEC payload packets
>
> and Retx packets:
>
>
> 1. R and F bits swapped places, which makes the retransmission bit first,
>
> thus copying the retransmission packet as is, would work because the
>
> RTP V bit would align with R=1,F=0 and nothing special needs to be
>
> handled in this case.
>
>
> 2. sequence number (SN base_i) replaces length recovery
>
>
> 3. SSRCCount and the reserved field is removed, as retx contains just
>
> a single packet from an SSRC.
>
>
>
> Regards,
>
> Varun and Mo.
>
>
> --
> http://www.callstats.io
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload
>

---

From: Varun Singh <[email-masked]>
Date: Tue, 16 Aug 2016 14:00:51 +0300

Hi Stefan,

The RTP header will follow the timing and payload rules for the RTP
stream. Further, an endpoint could intersperse retx and FEC packets,
which would make keeping track of sequence numbers difficult.

Regards,
Varun

On Tue, Aug 16, 2016 at 11:49 AM, Stefan Holmer <[email-masked]> wrote:
>>                 :
>> RTP payload                                                        :

-- 
Founder, CEO, callstats.io
http://www.callstats.io
Analytics and Optimizations for WebRTC.

We are hiring: www.callstats.io/jobs/

---

From: Stefan Holmer <[email-masked]>
Date: Tue, 16 Aug 2016 11:09:32 +0000

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?

I can see that it could be an issue if you retransmit packets from two
different rtp streams, where one is video and one is audio with a different
rtp timestamp rate. Is that the reason for this not being possible, or
could those be differentiated via payload types?

/Stefan

---

From: Varun Singh <[email-masked]>
Date: Thu, 18 Aug 2016 20:42:21 +0300

Hi Stefan,

On Tue, Aug 16, 2016 at 2:09 PM, Stefan Holmer <[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

see below.

> rtp timestamp rate. Is that the reason for this not being possible, or could
> those be differentiated via payload types?

Exactly. we can use the FEC stream to protect multiple RTP streams, in which
case this would not make sense. And we need to identify the FEC stream,
the payload type for the FEC packet is set in the SDP.

>> >>        |                          TS recovery
>> >> |
>> >>        |   SSRCCount   |                    reserved
>> >> |
>> >>        |                             SSRC_i
>> >> |
>> >>        |k|
>> >> |
>> >>        |
>> >> |
>> >>        |                          TS recovery
>> >> |
>> >>        |                             SSRC_i
>> >> |
>> >>        |                            timestamp
>> >> |
>> >>        |                               SSRC
>> >> |
>> >>        |                              Retx
>> >> |

---

From: Stefan Holmer <[email-masked]>
Date: Tue, 23 Aug 2016 11:48:02 +0000

On Thu, Aug 18, 2016 at 7:42 PM Varun Singh <[email-masked]> wrote:

> but

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.

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.

> could

Agree, it doesn't generalize well to protecting multiple streams. Thanks.

> >> > header when doing retransmits? Since the RTP timestamp should
> represent
> >> > the