Subject: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt

From: [email-masked]
Date: Tue, 11 Dec 2018 10:56:14 -0800

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-13.txt
	Pages           : 41
	Date            : 2018-12-11

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 scalability issues experienced with the earlier
   specifications, and offer several improvements.  Due to these
   changes, the new payload formats are not backward compatible with
   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-13
https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-scheme-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-flexible-fec-scheme-13

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/

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 11 Dec 2018 19:01:54 +0000

Please note that I cleared out as many nits as I thought made sense.  Current nit check showed zero errors, but a few warnings and comments.  I also updated the avtext-rid reference.

I modified the abstract slightly as inclusion of references violated RFC 7322, Sec. 4.3.   As a result, I removed those references from the abstract and added a sentence in the Introduction that provided the references.

-Giri Mandyam

-----Original Message-----
From: payload <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, December 11, 2018 10:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt

Abstract:

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.

_______________________________________________
payload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/payload

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Dec 2018 17:07:40 +0000

Hi,

Looking at the changes.

Section 7.1.1:
Regarding: c=IN IP4 233.252.0.1/127
Isn't keeping it as an unicast address a better approach here?

Note that https://tools.ietf.org/html/rfc5737 do have unicast ranges
which you can pick an address from.

I don't think there are any issues in itself with having a multicast
address here. However, people may get ideas, especially with both 7.1.1
and 7.1.2 using multicast.

Otherwise it appears that you have addressed those ID-nits you need to
address.

Cheers

Magnus

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Giridhar Mandyam <[email-masked]>
Date: Wed, 12 Dec 2018 18:40:54 +0000

> Isn't keeping it as an unicast address a better approach here?

2 reasons:

a) I didn't see a particular reason to have 2 different addresses in the examples.

b) The repair window in the example of Sec. 7.1.1 was small compared to the example in Sec. 7.1.2, which seems appropriate for live media over multicast.  Therefore I felt that a multicast delivery address could be appropriate.   {I did consider using localhost for the address (127.0.0.1), so as to provide a unicast address example that could represent an RTP proxy that intermediates between a multicast source and unicast receiver.  But this may imply restricted use of FLEX FEC as well, which is not desirable either.}

I can change one of the examples to something like 192.0.2.0/24, but I wonder if Sec. 7.1.2 may be more appropriate than 7.1.1.

-Giri

-----Original Message-----
From: Magnus Westerlund <[email-masked]> 
Sent: Wednesday, December 12, 2018 9:08 AM
To: Giridhar Mandyam <[email-masked]>; [email-masked]
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt

Hi,

Looking at the changes.

Section 7.1.1:

Note that https://tools.ietf.org/html/rfc5737 do have unicast ranges which you can pick an address from.

I don't think there are any issues in itself with having a multicast address here. However, people may get ideas, especially with both 7.1.1 and 7.1.2 using multicast.

Otherwise it appears that you have addressed those ID-nits you need to address.

Cheers

Magnus

On 2018-12-11 20:02, Giridhar Mandyam wrote:
> Subject: [payload] I-D Action: 
> draft-ietf-payload-flexible-fec-scheme-13.txt
>
>

-- 

Magnus Westerlund

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 13 Dec 2018 06:51:51 +0000

Magnus,
Is it OK to have the multicast address and can I send the document to publication?

Regards
Roni
-----Original Message-----
From: payload [mailto:[email-masked]] On Behalf Of Giridhar Mandyam
Sent: Wednesday, December 12, 2018 8:41 PM
To: Magnus Westerlund; [email-masked]
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt

2 reasons:

-Giri

-----Original Message-----
From: Magnus Westerlund <[email-masked]>
Sent: Wednesday, December 12, 2018 9:08 AM
To: Giridhar Mandyam <[email-masked]>; [email-masked]
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt

Hi,

Looking at the changes.

Section 7.1.1:

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 13 Dec 2018 11:49:20 +0000

> Is it OK to have the multicast address and can I send the document to publication?

Yes, it is. I don't think there are anything in this examples that are
not possible to work in multicast. It is just that I think a large part
of the usage of this specification will be in unicast.

Cheers

Magnus

-- 

Magnus Westerlund