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

[Magnus Westerlund <[e-mail]>]

On 2018-12-13 07:52, Roni Even (A) wrote:
> Magnus,
> 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



> Regards
> Roni
> -----Original Message-----
> From: payload [mailto:[e-mail]] On Behalf Of Giridhar Mandyam
> Sent: Wednesday, December 12, 2018 8:41 PM
> To: Magnus Westerlund; [e-mail]
> Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt
>
>> 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 <[e-mail]>
> Sent: Wednesday, December 12, 2018 9:08 AM
> To: Giridhar Mandyam <[e-mail]>om>; [e-mail]
> Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt
>
> 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
>
>
> On 2018-12-11 20:02, Giridhar Mandyam wrote:
>> 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 <[e-mail]> On Behalf Of 
>> [e-mail]
>> Sent: Tuesday, December 11, 2018 10:56 AM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: [payload] I-D Action: 
>> draft-ietf-payload-flexible-fec-scheme-13.txt
>>
>>
>> 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-schem
>> e/
>>
>> 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-sche
>> me-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/
>>
>> _______________________________________________
>> payload mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/payload
>>
>> _______________________________________________
>> 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]
----------------------------------------------------------------------