Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt

["Mo Zanaty (mzanaty)" <[e-mail]>]

5109 uses the old FEC semantics in SDP which were deprecated by FEC-FR. No FEC-FR encoding id has been defined yet for XOR parity with ULP. So there would be a bit more work to do.

As Colin points out though, ULP gives very little (if any) bang for lots of bucks, so reusing LDPC (XOR without ULP, which is already in FEC-FR) is perhaps a better alternative.

Some (including myself) also feel XOR is often ineffective for most real-world loss patterns. It is only useful for isolated single-packet loss, which is indeed useful for very highly multiplexed links like transcontinental / transoceanic paths. But it is mostly ineffective for low stat-mux environments like access links, especially wireless which often exhibits consecutive losses. (For this reason, we use RS which is complex but provides optimal repair.)

Mo

On Jul 16, 2014, at 11:16 PM, "Justin Uberti" <[e-mail]<mailto:[e-mail]>> wrote:

In DC we talked about making a baseline FEC proposal using 5109. Other variants could be added in the future, but 5109 would be MTI.

I still need to write up said proposal though, including explaining how it works with BUNDLE (it can do so fairly easily)


On Tue, Jul 15, 2014 at 6:15 PM, Mo Zanaty (mzanaty) <[e-mail]<mailto:[e-mail]>> wrote:
There is also RFC 6865 Reed Solomon FEC.

Since there are many encoding schemes (parity/LDPC, Raptor/Q, Reed
Solomon), many encoding-dependent variants (1d/2d interleaved, ULP,
staircase, triangle, etc.) and parameters (n,k,etc.), several RTP
packetization and multiplexing options, and several SDP expressions, it
seems premature to make any sort of FEC recommendation without some more
detailed work and discussion.

So I agree with the current draft text.

Mo

-----Original Message-----
From: Colin Perkins <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 15, 2014 at 11:53 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-15.txt

As far as I¹m aware, the only open issue with the RTP usage draft is
whether it should make some recommendation regarding FEC. The draft
currently states:

³There are several block-based FEC schemes that are designed for use with
RTP independent of the chosen RTP payload format.  At the time of this
writing there is no consensus on which, if any, of these FEC schemes is
appropriate for use in the WebRTC context.  Accordingly, this memo makes
no recommendation on the choice of block-based FEC for WebRTC use.²

but some people have expressed a desire that it recommend some FEC scheme.
As I understand it, the possible FEC schemes are as follows:

- RFC 2733 ­ parity FEC; requires FEC use same SSRC as original media, so
doesn¹t work with bundle; abuses RTP header fields for FEC, so can¹t be
used with mixers

- RFC 5109 ­ parity FEC with uneven level protection (ULP); unnecessary
complexity due to ULP; requires FEC use same SSRC as original media, so
doesn¹t work with bundle

- SMPTE 2022-1 ­ extends RFC 2733 for 2d interleaved parity FEC; sets CC,
CSRC, and timestamp to zero, so doesn¹t work with mixers; requires SSRC=0
and PT=96, so can¹t support >1 FEC stream per RTP session

- RFC 6015 ­ interleaved parity FEC; abuses RTP header fields for FEC, so
can¹t be used with mixers; works with bundle

- RFC 6682 ­ Raptor FEC; works with bundle

There are IPR declarations on most of these, most have problems with
bundle due to the way they use SSRCs, and some have problems with RTP
mixers due to the way they abuse the CC/CSRC header fields to convey
protection information. Accordingly, I don¹t see a particularly good
choice for WebRTC, and since we can add FEC in a backwards compatible
manner in a later revision of WebRTC, my proposal is that we leave it out.
However, I¹m open to other suggestions.

Also, if there are other open issues with the rtp-usage draft that I¹ve
missed, then please let me know.

Colin






On 28 May 2014, at 12:29, Magnus Westerlund
<[e-mail]<mailto:[e-mail]>> wrote:
> WG,
>
> This version contains some changes as result of last weeks discussion.
> Especially you who wasn't there should review this to see that you agree
> with the changes proposed.
>
> The changes are:
>
> - Multi-stream optimization are now a MAY support, MUST signal to use.
>
> - The T_rr_interval = 4 is now explained in
> draft-ietf-avtcore-rtp-multi-stream, so a reference has been added here.
>
> - Signalling of extensions has been clarified to be a MUST
>
> - The DoS potential from RTCP configuration that Martin Thomson noticed
> is now discussed and the general consideration that an WebRTC
> implementation needs safe guards among this is present. WG needs to
> consider if it needs more or are sufficient.
>
> Cheers
>
> Magnus
>
> On 2014-05-28 13:21, [e-mail]<mailto:[e-mail]> wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>> This draft is a work item of the Real-Time Communication in
>>WEB-browsers Working Group of the IETF.
>>
>>        Title           : Web Real-Time Communication (WebRTC): Media
>>Transport and Use of RTP
>>        Authors         : Colin Perkins
>>                          Magnus Westerlund
>>                          Joerg Ott
>>      Filename        : draft-ietf-rtcweb-rtp-usage-15.txt
>>      Pages           : 44
>>      Date            : 2014-05-28
>>
>> Abstract:
>>   The Web Real-Time Communication (WebRTC) framework provides support
>>   for direct interactive rich communication using audio, video, text,
>>   collaboration, games, etc. between two peers' web-browsers.  This
>>   memo describes the media transport aspects of the WebRTC framework.
>>   It specifies how the Real-time Transport Protocol (RTP) is used in
>>   the WebRTC context, and gives requirements for which RTP features,
>>   profiles, and extensions need to be supported.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-15
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-15
>>
>>
>> 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<http://tools.ietf.org>.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]<tel:%2B46%2010%207148287>
> Färögatan 6                 | Mobile [phone]<tel:%2B46%2073%200949079>
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]<mailto:[e-mail]>
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rtcweb



--
Colin Perkins
http://csperkins.org/



_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb