Subject: Re: [payload] FlexFEC draft feedback

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 7 Dec 2017 22:05:54 +0000

Hi Brian,

Thank you for the review and comments. We are updating the draft to address your comments as noted below (see Mo: inline).

Thanks,
Mo

From: payload <[email-masked]<mailto:[email-masked]>> on behalf of Brian Baldino <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 29, 2017 at 3:18 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [payload] FlexFEC draft feedback

I've been implementing flexfec on the jitsi videobridge (starting with just the receive side for now) and came across a couple things.  Also Boris Grozev has compiled some notes from his readings of the draft; I've tried to summarize all our thoughts here:

1) It would be nice if the draft mentioned that the header extensions of the FEC packets are totally independent of the media's header extensions, and that one can add extensions to FEC packets without having any effect on the recovery.

Mo: Agreed, will do.

2) It would be nice if the draft explicitly stated that RTP header extensions (and anything in the header beyond the 12 byte fixed header, really) is protected as part of the payload.

Mo: Agreed, will do. As noted in my reply to Stephen, a good word for that (bytes after 12) will greatly clarify things.

3) I don't think it's explicitly mentioned that the first bit of the mask represents a delta value of '0' (and, therefore, a '1' in that bit means that the base sequence number itself is protected), it would be nice to call this out [in Section 6.3.1.2 maybe?]

Mo: Agreed, will do.

4) In some of the diagrams there is a typo making it look like the 'P' field is 2 bits instead of 1 (Figures 10, 12, 13, and 15)

Mo: Yes, good catch.

4) From an implementation perspective, I found the extraction of the mask to be a bit of a pain due to having to extract the k bits and shift the actual mask to get the offsets.  I wondered if there was a reason not to move the second k bit next to the first to make them consecutive, followed by a consecutive mask.  I thought of two ways this might be done:

a) Put a 2 bit k field at the start of the mask.  There are multiple ways to define an encoding for those 2 bits to represent a 14, 46 or 110 mask.  This has the downside of making the first mask 1 bit smaller (14 bits vs 15) but does allow for encoding a 4th mask length, if so desired.

b) Put a variable (either 1 or 2) bit k field at the start of the mask.  Similar to the current scheme, if the first bit was a '1' it would mean it was only a 15 bit mask and the second bit would not be used to represent the mask size,  If the first bit was a '0', then the next bit will also be used to determine the mask size. I.e.:
1 -> 15 bit mask (only one bit spent)
01 -> 46 bit mask
00 -> 110 bit mask

Mo: The original -00 draft had this design in section 4.2:

   The FEC header consists of the following fields:

   o  The MSK field (2 bits) indicates the type of the mask.  Namely:

    +---------------+-------------------------------------+
    |    MSK bits   | Use                                 |
    +---------------+-------------------------------------+
    |      00       | 16-bit mask                         |
    |      01       | 48-bit mask                         |
    |      10       | 112-bit mask                        |
    |      11       | packets indicated by offset M and N |
    +---------------+-------------------------------------+

                         Figure 11: MSK bit values

Mo: When we added the optimized retransmission format, the MSK bits were replaced by the RF bits and the mask size was extended in each mask. If you want to convince the workgroup to move back to the original design or something similar, I am personally neutral on this point. But let's decide quickly either way.

-brian

---

From: Brian Baldino <[email-masked]>
Date: Thu, 7 Dec 2017 14:39:22 -0800

Hey Mo, thanks for the reply...definitely interested in the discussion
about the move, but I'm having trouble tracking it down.  I found this
<https://mailarchive.ietf.org/arch/msg/payload/MS5jMAYzZjs9LdJ4NeVXt8EWZMw>
email
about retransmission optimization, but it looks like the 'k' bit scheme was
already in use there.  In the -02 draft (where the MSK bits are removed) I
see in the changelog that the format was updated to reflect
discussions in IETF94,
Tokyo...does that mean perhaps that discussion was all in person, and not
on the mailing list?  Searching the list archives for 'msk' didn't turn up
much either, but maybe I'm missing something.

If the group was convinced to move away from it, not sure I'd have anything
that would sway people back, but I'd be interested to read about the
reasons.  And can certainly testify that implementing it was not very fun
(though having to do it in Java didn't do me any favors, either).

-brian

On Thu, Dec 7, 2017 at 2:05 PM, Mo Zanaty (mzanaty) <[email-masked]>
wrote:

> Hi Brian,
>
> Thank you for the review and comments. We are updating the draft to
> address your comments as noted below (see Mo: inline).
>
> Thanks,
> Mo
>
>
> From: payload <[email-masked]> on behalf of Brian Baldino <
> [email-masked]>
> To: "[email-masked]" <[email-masked]>
> I've been implementing flexfec on the jitsi videobridge (starting with
> just the receive side for now) and came across a couple things.  Also Boris
> Grozev has compiled some notes from his readings of the draft; I've tried
> to summarize all our thoughts here:
>
> 1) It would be nice if the draft mentioned that the header extensions of
> the FEC packets are totally independent of the media's header extensions,
> and that one can add extensions to FEC packets without having any effect on
> the recovery.
>
> Mo: Agreed, will do.
>
> 2) It would be nice if the draft explicitly stated that RTP header
> extensions (and anything in the header beyond the 12 byte fixed header,
> really) is protected as part of the payload.
>
> Mo: Agreed, will do. As noted in my reply to Stephen, a good word for that
> (bytes after 12) will greatly clarify things.
>
> 3) I don't think it's explicitly mentioned that the first bit of the mask
> represents a delta value of '0' (and, therefore, a '1' in that bit means
> that the base sequence number itself is protected), it would be nice to
> call this out [in Section 6.3.1.2 maybe?]
>
> Mo: Agreed, will do.
>
> 4) In some of the diagrams there is a typo making it look like the 'P'
> field is 2 bits instead of 1 (Figures 10, 12, 13, and 15)
>
> Mo: Yes, good catch.
>
> 4) From an implementation perspective, I found the extraction of the mask
> to be a bit of a pain due to having to extract the k bits and shift the
> actual mask to get the offsets.  I wondered if there was a reason not to
> move the second k bit next to the first to make them consecutive, followed
> by a consecutive mask.  I thought of two ways this might be done:
>
> a) Put a 2 bit k field at the start of the mask.  There are multiple ways
> to define an encoding for those 2 bits to represent a 14, 46 or 110 mask.
> This has the downside of making the first mask 1 bit smaller (14 bits vs
> 15) but does allow for encoding a 4th mask length, if so desired.
>
> b) Put a variable (either 1 or 2) bit k field at the start of the mask.
> Similar to the current scheme, if the first bit was a '1' it would mean it
> was only a 15 bit mask and the second bit would not be used to represent
> the mask size,  If the first bit was a '0', then the next bit will also be
> used to determine the mask size. I.e.:
> Mo: When we added the optimized retransmission format, the MSK bits were
> replaced by the RF bits and the mask size was extended in each mask. If you
> want to convince the workgroup to move back to the original design or
> something similar, I am personally neutral on this point. But let's decide
> quickly either way.
>
>
> -brian
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 7 Dec 2017 22:55:04 +0000

The minutes from that meeting are terse, but perhaps the recordings are an option if you have the patience?
https://www.ietf.org/proceedings/94/payload.html

Or maybe Varun recalls the reasons. I don't recall any strong argument either way on that point. I don't have any personal preference either.

Thanks,
Mo

From: <[email-masked]<mailto:[email-masked]>> on behalf of Brian Baldino <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 7, 2017 at 5:39 PM
To: mzanaty <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [payload] FlexFEC draft feedback

Hey Mo, thanks for the reply...definitely interested in the discussion about the move, but I'm having trouble tracking it down.  I found this<https://mailarchive.ietf.org/arch/msg/payload/MS5jMAYzZjs9LdJ4NeVXt8EWZMw> email about retransmission optimization, but it looks like the 'k' bit scheme was already in use there.  In the -02 draft (where the MSK bits are removed) I see in the changelog that the format was updated to reflect discussions in IETF94, Tokyo...does that mean perhaps that discussion was all in person, and not on the mailing list?  Searching the list archives for 'msk' didn't turn up much either, but maybe I'm missing something.

If the group was convinced to move away from it, not sure I'd have anything that would sway people back, but I'd be interested to read about the reasons.  And can certainly testify that implementing it was not very fun (though having to do it in Java didn't do me any favors, either).

-brian

On Thu, Dec 7, 2017 at 2:05 PM, Mo Zanaty (mzanaty) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian,

Thanks,
Mo

Mo: Agreed, will do.

Mo: Agreed, will do.

Mo: Yes, good catch.

-brian

---

From: Boris Grozev <[email-masked]>
Date: Thu, 7 Dec 2017 19:47:47 -0600

Hello,

On 07/12/2017 16:55, Mo Zanaty (mzanaty) wrote:
> Or maybe Varun recalls the reasons. I don't recall any strong argument 
> either way on that point. I don't have any personal preference either.

Note that Brian's suggestion "b" is equivalent to the -05 format in 
terms of the sets of sequence numbers that it can describe and the 
number of bits used for any given set. It only moves the second part of 
the "k" field, so that it's two bits (if both are present) are consecutive.

If there are reasons for switching away from the fixed-length 2-bit 
field, or if time constraints make it hard to determine whether there 
are such reasons, please consider adopting this format. It is "safe" in 
that it doesn't change any higher level protocol characteristics, and 
more convenient for implementers.

Regards,
Boris