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

[Giridhar Mandyam <[e-mail]>]

> 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]
----------------------------------------------------------------------