Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-11.txt

[Magnus Westerlund <[e-mail]>]

Hi,

I have now checked this document against my previous comments. I have
two outstanding issues.

1. Section 5.1.1 and additonal ones:

  o  ToP: indicates the type of protection applied by the sender: 0 for
      1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC
      protection, 2 for 2-D parity FEC protection, and 3 for
      retransmission.  There can only be one value listed for ToP.

At least in discussing this with Mo F2F I got the impression that the
plan was to also be explicit about what the lack of it means, i.e. it
can be any of the self describing usages, so a mix of retransmission and
FEC is possible.

2. Also my original comment O. on version -08 has not bee answered:

O. Section 7:
The use of draft-ietf-avtext-rid RepairedRtpStreamId is not at all 
needed, even if it could be used in a sub-set of applications of 
flexfec. It would work in same RTP Session, with a single repair RTP 
stream only protects a singe source RTP stream. But, considering the 
possibility of repair of multiple source streams and different RTP 
Sessions, I think an explicit statement that this SHOULD NOT be used for 
the payload format would be good to include.

Please indicate your thoughts on this matter.

Cheers

Magnus Westerlund




On 2018-11-19 06:22, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Audio/Video Transport Payloads WG of the IETF.
>
>         Title           : RTP Payload Format for Flexible Forward Error Correction (FEC)
>         Authors         : Mo Zanaty
>                           Varun Singh
>                           Ali Begen
>                           Giridhar Mandyam
> 	Filename        : draft-ietf-payload-flexible-fec-scheme-11.txt
> 	Pages           : 41
> 	Date            : 2018-11-18
>
> Abstract:
>    This document defines new RTP payload formats for the Forward Error
>    Correction (FEC) packets that are generated by the non-interleaved
>    and interleaved parity codes from source media encapsulated in RTP.
>    These parity codes are systematic codes, where a number of FEC repair
>    packets are generated from a set of source packets from one or more
>    source RTP streams.  These FEC repair packets are sent in a
>    redundancy RTP stream separate from the source RTP stream(s) that
>    carries the source packets.  RTP source packets that were lost in
>    transmission can be reconstructed using the source and repair packets
>    that were received.  The non-interleaved and interleaved parity codes
>    which are defined in this specification offer a good protection
>    against random and bursty packet losses, respectively, at a cost of
>    decent complexity.  The RTP payload formats that are defined in this
>    document address the scalability issues experienced with the earlier
>    specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and
>    offer several improvements.  Due to these changes, the new payload
>    formats are not backward compatible with the earlier specifications,
>    but endpoints that do not implement this specification can still work
>    by simply ignoring the FEC repair packets.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11
> https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-scheme-11
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-flexible-fec-scheme-11
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> payload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/payload
>

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------