Re: [rtcweb] Review of draft-ietf-rtcweb-rtp-usage

[Colin Perkins <[e-mail]>]

On 7 May 2014, at 20:25, Bernard Aboba <[e-mail]> wrote:
> Here are a few things that caught my eye in re-reading draft-ietf-rtcweb-rtp-usage:
> 
> Circuit Breaker requirements
> 
> Section 7.1
> 
>    In the absence of a concrete congestion control algorithm, all WebRTC
>    implementations MUST implement the RTP circuit breaker algorithm that
>    is described in [I-D.ietf-avtcore-rtp-circuit-breakers].
> 
> [BA] What does "concrete" mean here?  There are a number of congestion control algorithms that one might or might not consider "concrete".  Also at various meetings, I have heard people talk about implementation of Circuit Breakers along with congestion control algorithms. 

The fix here is to delete “In the absence of a concrete congestion control algorithm, all”, leaving the text as “WebRTC implementations MUST implement the RTP circuit breaker…” since as you note, we want the circuit breaker even if there is congestion control.

> Personally, I would consider sender-side congestion control algorithms to qualify as "concrete", assuming that the algorithm could function adequately when interacting with standards-based implementations only supporting the functionality described in the RTP usage document (e.g. RTCP reports, etc.).  I am not sure that receiver-side congestion control mechanisms should qualify as “concrete" if they require both sender and receiver to implement proprietary functionality for congestion control to function adequately.

By “concrete”, I just meant something where you could point to an RFC and say “there is agreement that this is a reasonable choice for a congestion control algorithm”. 

> SDP dependencies
> 
> Since WebRTC is signaling-independent, at various points in discussion of the RTP usage document, it has been pointed out that it is not appropriate to mandate SDP signaling.  However, in re-reading the draft, a number of SDP mandates still remain.  I’d like to see these changed to state the requirement more generically, with guidance provided on what to do if SDP signaling is used.

Other than that in Section 4.8 you highlight below, did you find any other specific places that need changing? I had thought we’d fixed these already, but if you have any we missed, please let us know.

> Section 4.8
> 
>    Implementations are REQUIRED to support signalled RTP synchronisation
>    source (SSRC) identifiers, using the "a=ssrc:" SDP attribute defined
>    in Section 4.1 and Section 5 of [RFC5576].  Implementations MUST also
>    support the "previous-ssrc" source attribute defined in Section 6.2 of [RFC5576].  Other per-SSRC attributes defined in [RFC5576] MAY be
>    supported.
> 
> Propose this be changed to:
> 
> 
>    Implementations are REQUIRED to support signalled RTP synchronisation
>    source (SSRC) identifiers.  In an SDP context, this can be done using the “a=ssrc:" SDP attribute defined in Section 4.1 and Section 5 of [RFC5576] in addition to the "previous-ssrc" source attribute defined in Section 6.2; other per-SSRC attributes defined in [RFC5576] MAY be supported.

I rephrased this slightly as:

        <t>Implementations are REQUIRED to support signalled RTP
        synchronisation source (SSRC) identifiers. If SDP is used, this MUST
        be done using the "a=ssrc:" SDP attribute defined in Section 4.1 and
        Section 5 of <xref target="RFC5576"/> and the "previous-ssrc" source
        attribute defined in Section 6.2 of <xref target="RFC5576"/>; other
        per-SSRC attributes defined in <xref target="RFC5576"/> MAY be
        supported.</t>

Colin


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