Re: [payload] Updates on FLEX FEC (ver -19)

[Cullen Jennings <[e-mail]>]

> On Mar 28, 2019, at 12:18 PM, Giridhar Mandyam <[e-mail]> wrote:
> 
> b) Elimination of all optional SDP parameters (e.g. ToP, L and D fields).  This means that the sender can send any FEC configuration (as indicated by the FEC header) as long as it stays consistent with the mandatory SDP parameters (rate and repair window).  Sec. 1.1.6, 1.1.7, 4.2.2, and 5 are the primary impacted sections.  We believe this will greatly simplify SDP O/A and while retaining the "flexibility" of FLEX FEC to adapt FEC repair data on a packet-by-packet basis. 
> 	- Note that L and D cannot be larger than 255, respectively.  As we gain implementation experience, if we decide that 255 is not sufficient then it could be possible to extend the corresponding header fields in the future. Currently there are header values that are reserved (R=F=1 and  L=D=0) that could be used to indicate the use of an extended L and D field, as an example of one way to implement extended fields for L and D.

I’m strongly apposed to making this huge change at this late stage. It means the receiver has no ability to influence the FEC even thought on small device it may need to. It is just as important for the receiver to be able to have influence over what happens as the sender. We should not remove this. Removing this will cause some people to just keep using old FEC schemes instead of moving to something even as simply 1D with flex fec. 

I know we wish everyone would implement the most advanced version of everything we specify, but this will have the opposite effect of just deciding not to implement it at all.