Subject: [rtcweb] #27: Section 6.2 FEC

From: "rtcweb issue tracker" <[email-masked]>
Date: Sun, 25 Aug 2013 23:10:00 -0000

#27: Section 6.2 FEC

 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.

 [BA] While I realize that it is not easy to decide on which FEC scheme is
 appropriate for WebRTC, including a recommendation on retransmission but
 not FEC is problematic.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-rtcweb-rtp-
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:  milestone1
Component:  rtp-usage                |    Version:  1.0
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/27>
rtcweb <http://tools.ietf.org/rtcweb/>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Aug 2013 08:10:57 +0200

>  appropriate for WebRTC, including a recommendation on retransmission but

Bernard, this is the WG consensus that we so far have arrived on. If you
have a proposal regarding FEC, please make it and lets see if we can
reach consensus on such a proposal.

However, I fail to see how this is generally problematic. Retransmission
will cover certain parts of the deployment cases when the transport RTT
and delay does not prevent it from being able to repair in a timely
fashion. FEC clearly covers transport characteristics where
retransmission will show its shortcomings. If one want improved
transport performance in those cases clearly a common implemented FEC
solution is desired.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "rtcweb issue tracker" <[email-masked]>
Date: Mon, 26 Aug 2013 07:18:19 -0000

#27: Section 6.2 FEC

Comment (by [email-masked]):

 [Magnus Westerlund]

 [BA] FEC is discussed in Sections 1.1.7 and 3.3 of draft-roach-mmusic-
 unified-plan, with examples how it might be declared using SDP, so I found
 it a bit odd that draft-ietf-rtcweb-rtp-usage only had recommendations for
 RTX, not FEC.  For example, Section 1.1.7 says:

    For robust applications, techniques like RTX and FEC are used to
    protect media, and simulcast/layered coding can be used to provide
    support to heterogeneous receivers.  It needs to be possible to
    support these techniques, allow the recipient to optionally use or
    not use them on a source-by-source basis; and for simulcast/layered
    scenarios, to control which simulcast streams or layers are received.

 Here is what Section 3.3 says:

 3.3.  Handling of Simulcast, Forward Error Correction, and
       Retransmission Streams

    Simulcast refers to taking a single capture (e.g., a camera), and
    encoding it multiple times at different resolutions and / or frame
    rates.  For example, a device with a single HD camera may send one
    version of the video at full HD resolution, and a second version
    encoded at a low resolution.  This would allow a video conferencing
    bridge to be able to send the high resolution copy to some
    destination and low resolution copy to other destinations without
    having to recode the video at the conference bridge.

    Forward Error Correction (FEC) and Retransmission (RTX) streams are
    techniques that can provide stream robustness in the face of packet
    loss.  These approaches frequently make use of different payload
    types and different SSRC values than the stream to which they apply.

    In cases where a media source needs to correspond to more than one
    RTP flow, e.g.  RTX, FEC, or simulcast, the a=ssrc-group [RFC5576]
    concept is used to create a grouping of SSRCs for a single media
    stream track.  Each SSRC is declared using a=ssrc attributes, the
    same MSID is shared between the SSRCs, and the a=ssrc-group attribute
    defines the behavior of the grouped SSRCs.

    These groupings are used to perform demux of the incoming RTP streams
    and associate them (by SSRC) with their primary flows (modulo the
    behavior described in Section 3.2.1, if applicable).  This
    multiplexing of RTX and FEC in a single RTP session is already well-
    defined; RTX SSRC-multiplexing behavior is defined in [RFC4588], and
    FEC SSRC-multiplexing behavior is defined in [RFC5956].

    Note that both RTC and FEC also include SDP expressions that use
    different m= lines for the correction streams (cf.  [RFC4588],
    section 8.7 and [RFC5956], section 4.2).  These formats intend for
    correlation of streams to be based on transport addresses, which is
    inapplicable for bundled media streams.  Our specific proposal is:
    (1) bundling implementations will never generate such a format; and
    (2) bundling implementations MAY choose to accept SDP in such a
    format or MAY simply reject the repair streams and proceed as if the
    indicated repair format is not supported.

    For multi-resolution simulcast, we can create a similar ssrc-group,
    and adapt the imageattr attribute defined in [RFC6236] for the a=ssrc
    line attribute to indicate the send resolution for a given simulcast
    stream.  (This will be added to
    [I-D.westerlund-avtcore-rtp-simulcast], as outlined in Section 2,
    bullet 1).  In the example below, the SDP advertises a simulcast of a
    camera source at two different resolutions, as well as a screen-share
    source that supports RTX; a=ssrc-group is used to correlate the
    different SSRCs as part of a single media source.

    Note that a characteristic of this approach is that it does not allow
    for independently setting attributes for simulcast, FEC, and RTX
    streams aside from those in fmtp.  In particular, attributes such as
    ptime and framerate are shared between the streams that are grouped
    together for a simulcast group.

    m=video 62537 RTP/SAVPF 96       // main video
    a=msid:ma ta
    a=extmap:1 urn:ietf:params:rtp-hdrext:stream-correlator 15955
    a=mid:1
    a=rtpmap:96 VP8/90000
    a=sendrecv
    a=rtcp-mux
    a=ssrc:29154 imageattr:96 [x=1280,y=720]
    a=ssrc:47182 imageattr:96 [x=640,y=360]
    a=ssrc-group:SIMULCAST 29154 47182
    m=video 0 RTP/SAVPF 96 97          // slide video
    a=msid:ma tb
    a=extmap:1 urn:ietf:params:rtp-hdrext:stream-correlator 26267
    a=mid:2
    a=rtpmap:96 VP8/90000
    a=rtpmap:97 rtx/90000
    a=sendrecv
    a=rtcp-mux
    a=fmtp:97 apt=96;rtx-time=3000
    a=ssrc:45982
    a=ssrc:9827
    a=ssrc-group:FID 45982 9827        // FID provides SSRC correlation
    a=bundle-only

    Providing explicit resolutions on a per-SSRC basis for SIMULCAST
    groupings allows an intermediary (such as a Media Translator
    [RFC5117]) to be able to select an appropriate SIMULCAST layer
    without inspecting the media stream, which could otherwise require
    decrypting and possibly partially decoding media packets.

 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |

Ticket URL: <http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/27#comment:1>
rtcweb <http://tools.ietf.org/rtcweb/>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 26 Aug 2013 16:51:07 +0100

On 26 Aug 2013, at 08:18, rtcweb issue tracker <[email-masked]> wrote:
> Bernard, this is the WG consensus that we so far have arrived on. If you have a proposal regarding FEC, please make it and lets see if we can reach consensus on such a proposal.
> 
> However, I fail to see how this is generally problematic. Retransmission will cover certain parts of the deployment cases when the transport RTT and delay does not prevent it from being able to repair in a timely fashion. FEC clearly covers transport characteristics where retransmission will show its shortcomings. If one want improved transport performance in those cases clearly a common implemented FEC solution is desired.
> 
> [BA] FEC is discussed in Sections 1.1.7 and 3.3 of draft-roach-mmusic- unified-plan, with examples how it might be declared using SDP, so I found it a bit odd that draft-ietf-rtcweb-rtp-usage only had recommendations for RTX, not FEC.  For example, Section 1.1.7 says:
> 

I don't see anything in this section that conflicts with rtp-usage draft.

> 3.3.  Handling of Simulcast, Forward Error Correction, and

...

Again, that all seems reasonable, but doesn't address the issue of what type of FEC to use. Like Magnus, I don't see working group consensus to recommend a particular FEC scheme. If you believe there is consensus on using a particular FEC scheme, make a proposal, and we'll incorporate it if accepted. 

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 26 Aug 2013 11:13:56 -0700

Colin said: 
"Again, that all seems reasonable, but doesn't address the issue of what type of FEC to use. Like Magnus, I don't see working group consensus to recommend a particular FEC scheme. If you believe there is consensus on using a particular FEC scheme, make a proposal, and we'll incorporate it if accepted. "

[BA] I assumed (rightly? wrongly?) that the FEC section of the Unified Plan document was put there with the intent to enable FEC to be indicated in the (SDP-based) API. Assuming that was the intent, and that the capability is developed further,  it would be useful for the supported FEC schemes to be documented somewhere, so as to enable interoperability.  I'll leave it to those who worked on the document to clarify where the RTX/FEC section is headed.

---

From: "Roni Even" <[email-masked]>
Date: Mon, 26 Aug 2013 21:48:36 +0300

So for FEC need to support RFC5956 and RFC6364 for signaling but no specific
FEC scheme
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Colin Perkins
> Sent: 26 August, 2013 6:51 PM
> To: rtcweb issue tracker
> Cc: [email-masked]; [email-masked]
> Subject: Re: [rtcweb] #27: Section 6.2 FEC
> 
> have a proposal regarding FEC, please make it and lets see if we can reach
> consensus on such a proposal.
> >
will
> cover certain parts of the deployment cases when the transport RTT and
> delay does not prevent it from being able to repair in a timely fashion.
FEC
> clearly covers transport characteristics where retransmission will show
its
> shortcomings. If one want improved transport performance in those cases
> clearly a common implemented FEC solution is desired.
> >
it
> a bit odd that draft-ietf-rtcweb-rtp-usage only had recommendations for
> Again, that all seems reasonable, but doesn't address the issue of what
type
> of FEC to use. Like Magnus, I don't see working group consensus to
> recommend a particular FEC scheme. If you believe there is consensus on
> using a particular FEC scheme, make a proposal, and we'll incorporate it
if
> accepted.
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 26 Aug 2013 16:40:50 -0700

Roni said: 

> So for FEC need to support RFC5956 and RFC6364 for signaling but no specific FEC scheme

[BA] Those are the relevant RFCs I would gather from the "Unified Plan" doc, but of course it makes no sense to define an API to control FEC without knowing what specific FEC schemes are going to be supported.   Such an API wouldn't just potentially differ in specifics between browser implementations, it might not potentially interoperate over the wire.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 27 Aug 2013 08:03:57 +0200

On 2013-08-26 20:13, Bernard Aboba wrote:
> Colin said: 
> 
> "Again, that all seems reasonable, but doesn't address the issue of what
> type of FEC to use. Like Magnus, I don't see working group consensus to
> if accepted. "
> [BA] I assumed (rightly? wrongly?) that the FEC section of the Unified
> Plan document was put there with the intent to enable FEC to be
> indicated in the (SDP-based) API. Assuming that was the intent, and that
> the capability is developed further,  it would be useful for the
> supported FEC schemes to be documented somewhere, so as to enable
> interoperability.  I'll leave it to those who worked on the document to
> clarify where the RTX/FEC section is headed.  

To my understanding unified plan includes this because it is considered
a general requirement to support this type of functionality for any
multi media stream usages of RTP sessions as indicated by SDP. Thus the
discussion makes sense in the context of unified plan as being important
to show that it can be done.

When it comes to the rtp-usage document I don't see any issues with
negotiating the usage of FEC mechanism of the implementors choice using
what ever negotiation mechanism one has, at this stage presumably SDP
O/A. However, unless the WG can come to a consensus on what the FEC
mechanisms and their usages is to be, describing all the options and
deployment choices is a significant task that I frankly don't see as
improving interoperability. Thus, unless the WG do come to consensus on
some specific choices I find it difficult to write anything in RTP usage.

Bernard, if you have an idea of what you like to see here, can you
please propose some text.

Cheers

Magnus Westerlund