Re: [rtcweb] Working Group Last Call for draft-ietf-rtcweb-rtp-usage-13

[Magnus Westerlund <[e-mail]>]

Hi Suhas,

Thanks, for your review, please see comments and answers inline.

On 2014-05-10 01:36, Suhas Nandakumar wrote:
> Thanks Magnus and all for this work. I liked the way the document has
> turned out to be.
> 
> Apologies for the last minute response, I am been wanting  to read this
> spec and finally got some time late in this week.
> 
> I have listed down few points that reflect my notes when i read the
> document from a RTP implementor and WebRTC developer perspectives.
> 
> *Comments*
> 
> 
> 2. Handling of documents from AVTCore related to MultiStream,
> MultiStreamOptimization, MultiMediaRTPSession that are normatively
> referenced. It was not clear if all these should be normatively referenced. 

Yes, they are most definitely normative references here.
- Multi-stream is the general clarification on handling multi-stream.
>From my perspective these clarifications are definitely needed.

- MultiStreamOptimization we RECOMMEND due to the significant gain it
provides as soon as each endpoint have multiple SSRCs.

- MultiMediaRTPSession is a requirement to allow for audio and video in
the same RTP session.

> 
> 3. RTP Taxonomy usage. This comment is applicable to the RTP documents
> referred by this document which dont follow the Taxonomy. This caused
> lot of concept mapping in my mind to go between the different usages to
> understand the implications. I would strongly recommend alignment with
> the Taxonomy for these dependent documents and I volunteer to do some of
> it If needed.

Yes, but that has to happen for each document individually. I think this
document is pretty well aligned with the current Taxonomy draft.

> 
> 4. trr-int of 4 seconds has be recommended in couples of places. But i
> dont see a reference to the choice of 4 seconds and the reason why it
> was chosen that way. I am not sure if we want to specify this detail in
> this document.

Yes, the motivation behind this value is from the attached presentation.
Please see slide 11, where you can see the curves for how many actual
reporting intervals will occur before an AVP and AVPF respectively will
on average time out the other profile type based on different values for
t-rr-int. A t-rr-int=4 s optimizes the number of reporting interval for
well configured RTP sessions. The well configured is meant to avoid the
AVPF bad behaviour when Td becomes close to T-rr-int. The first part of
the presentation discusses that issue and can be worth reading through
also.

> 
> 5. Section 4.1 says,
> 
>   * Support for multiple end-points in a single RTP session, and for
>     scaling the RTCP transmission interval according to the number of
>     participants in the session; support for randomised RTCP
>     transmission intervals to avoid synchronisation of RTCP reports;
>     support for RTCP timer reconsideration.
> 
> All these MUST requirements need references. If some of these belong to
> RFC3550, then we need to say that. 

We propose:

   o  Support for multiple end-points in a single RTP session, and for
      scaling the RTCP transmission interval according to the number of
      participants in the session; support for randomised RTCP
      transmission intervals to avoid synchronisation of RTCP reports;
      support for RTCP timer reconsideration (Section 6.3.6 of
      [RFC3550]) and reverse reconsideration (Section 6.3.4 of
      [RFC3550]).


> 
> 6. Section 4.2
>      Not sure if the side note for trr-int fits in this section

I think it fits well enough. The section discusses the profiles, and a
relevant consideration is the legacy interop with AVP/SAVP senders. Do
you have a suggestion where it should be placed instead?

> 
> 7. Section 4.3 Para 2
>       - I felt this Para was getting too busy in laying out the cases of
> PT Reuse combinations. Can we break it , if possible ?

Is this better?

   End-points can signal support for multiple RTP payload formats, or
   multiple configurations of a single RTP payload format, as long as
   each unique RTP payload format configuration uses a different RTP
   payload type number.  As outlined in Section 4.8, the RTP payload
   type number is sometimes used to associate an RTP packet stream with
   a signalling context.  This association is possible provided unique
   RTP payload type numbers are used in each context.  For example, an
   RTP packet stream can be associated with an SDP "m=" line by
   comparing the RTP payload type numbers used by the RTP packet stream
   with payload types signalled in the "a=rtpmap:" lines in the media
   sections of the SDP.  This leads to the following considerations:

      If RTP packet streams are being associated with signalling
      contexts based on the RTP payload type, then the assignment of RTP
      payload type numbers MUST be unique across signalling contexts.

      If the same RTP payload format configuration is used in multiple
      contexts, then a different RTP payload type number has to be
      assigned in each context to ensure uniqueness.

      If the RTP payload type number is not being used to associate RTP
      packet streams with a signalling context, then the same RTP
      payload type number can be used to indicate the exact same RTP
      payload format configuration in multiple contexts.

   A single RTP payload type number MUST NOT be assigned to different
   RTP payload formats, or different configurations of the same RTP
   payload format, within a single RTP session.


>       - We can probably delete the note referring to BUNDLE spec since
> we refer to it again in Section 4.4 where it contextually makes more sense.

Ok, I do think it works to remove this:

	(note that the different
   "m=" lines in an SDP bundle group
   [I-D.ietf-mmusic-sdp-bundle-negotiation] form a single RTP session)

>         
> 8. Section 4.3 Para 3
>    An end-point that has signalled support for multiple RTP payload
> formats SHOULD be able to accept data in any of those payload formats at
> any time, unless it has previously signalled limitations on its decoding
> capability.
> 
> Shouldn't the SHOULD be MUST above. If not, I think we fail interoperability

Yes, will be included in the next version.

> 
> 9.Nit ..  Section 4.4 Para 3 says
> Further discussion about the suitability of different RTP session
> structures and multiplexing methods to different scenarios are suitable
> can be found in [I-D.ietf-avtcore-multiplex-guidelines]
> <http://tools.ietf.org/id/draft-ietf-rtcweb-rtp-usage-13.html#I-D.ietf-avtcore-multiplex-guidelines>.
> 
> How about rewording it to,
> Further discussion about the suitability of different RTP session
> structures and multiplexing methods to different scenarios can be found
> in [I-D.ietf-avtcore-multiplex-guidelines]
> <http://tools.ietf.org/id/draft-ietf-rtcweb-rtp-usage-13.html#I-D.ietf-avtcore-multiplex-guidelines>.
> 

Sounds better, will incorporate.

> 
> 10.  Section 5.1 ( Topology Recommendations)
>        - Nit .. Adding reference to RTCPeerConnections might be useful

Sure, will add.

>        - I dont think this document should make recommendations against
> applicability of a particular topology for a given context.
> Specifically, the pointers to carrying out congestion control mechanisms
> are still under development and denying a topology based on it might not
> be a good idea. I would prefer this section referring to the Topo
> document as an informative reference and implications of each topology
> under various scenarios should be moved in there, if needed.

That would also have been my preference. However, when this was
discussed in detail at the Stockholm RTCWEB Interim 2 years ago, people
has strong view that they where not willing to deal with the
implications of these topologies.

The issue with Transport relay as well as an Any Source Multicast group
is that each participating endpoint are required to handle multiple
congestion control loops, one to each receiving endpoint and act on the
full set of different path with a common appropriately selected
response. These type of topologies are explicitly outside of the charter
of RMCAT.

The Video switching MCU as defined in the topologies draft cause
breakage and inconsistencies in the RTP packet streams that are
difficult to handle and can result in strange congestion control
responses. That is why this is SHOULD NOT.

Please note that I started this effort with an intention of avoiding to
make the WebRTC endpoint limited in their deployment. With that in mind
I do see this set of limitations as a reasonable limitations.

> 
> 11. Section 5.1.2 
>       Should we add the requirement for the WebRTC end-point sending PLI
> messages?

Sorry, I am uncertain what you request here. The current section
requires an WebRTC RTP (video) sender to support PLI. The transmission
of PLI from the RTP receiving endpoint is a MAY. Do you want to change
this MAY to something else? A MUST? Please clarify your request.


> 
> 12. Section 10
>      - Nit - Reference to ICE is needed

Okay, will include.

> 
> 13. Section 11 Para 3
>        Not sure, if this is needed altogether. Probably saying a given
> Media Source might end up in several RTP Packet Streams  with their
> associated SSRC following WebRTC API mechanisms defined in <ref>

I disagree. The following sentence did take some discussion to arrive at:

"As different sets of constraints or other parameters can be applied to
the MediaStreamTrack, each MediaStreamTrack instance added to a
RTCPeerConnection SHALL result in an independent source packet stream,
with its own set of associated packet streams, and thus different SSRC(s)."

Yes, it is in the grey zone between W3C and IETF. However, in this case
we have worked for a WG consensus on that this is needed guidance to
W3C. Because there are different choices here and leaving it unspecified
is bad. Leaving it to W3C soley could result in ignoring the media
framework implications of what the API allows.

> 
>  14. Section 11 says
>  Note: this doesn't result in a tracking issue, since the creation of
> matching CNAMEs depends on existing tracking.
>   
>   We need bit more context here explaining the tracking or remove it
> altogether

So the sentence in the prior paragraph is not sufficient reference to
what it is?

   Having two
   communication sessions with the same CNAME could enable tracking of a
   user or device across different services (see Section 4.4.1 of
   [I-D.ietf-rtcweb-security] for details).



> 
> 15. Section 8
>       There is no requirement that the data contained in such reports be
> used, or exposed to the Javascript application, however.
>   Do we need this sentence ?

With the current formulation I would say yes. It makes it clear that
unless you have explicitly negotiated its use, you are not required to
handle them in any form other than ignoring such XR reports.

I have started a discussion with my co-author about that last paragraph
and to see if we can resolve it differently. Thus, this may be changed
but, we like to consider the most appropriate action to take care also
of Cullen's comment.

> 
> 16. Section 11 has,
> The above will currently force a WebRTC end-point that receives an
> MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing on
> any RTCPeerConnection to perform resynchronisation of the stream. This,
> as the sending party needs to change the CNAME, which implies that it
> has to use a locally available system clock as timebase for the
> synchronisation. Thus, the relative relation between the timebase of the
> incoming stream and the system sending out needs to defined. This
> relation also needs monitoring for clock drift and likely adjustments of
> the synchronisation. The sending entity is also responsible for
> congestion control for its the sent streams. In cases of packet loss the
> loss of incoming data also needs to be handled. This leads to the
> observation that the method that is least likely to cause issues or
> interruptions in the outgoing source packet stream is a model of full
> decoding, including repair etc followed by encoding of the media again
> into the outgoing packet stream. Optimisations of this method is clearly
> possible and implementation specific.
> 
> Probably,I am missing the context here, but I don't see the need for
> this para in this document since it is very application specific

Actually this is not application specific. It something that is way to
easy to do in the API to add an stream that is incoming over one
peerConnection and add it as outgoing on another. The WG has discussed
this and come to the consensus that we what is required by the WebRTC
implementations are to do what is described in the above text. Thus this
is something all WebRTC endpoints that supports the API will need to
handle.

I propose no change.

> 
> 17 Section 12
>     - Not sure if we really need the topology details in here. But I am
> fine going with it one way or the other.

As you say you have no issue, I would leave it in. You probably have a
good understanding what is written here. I think for a significant
number of people this will provide important information and understanding.

I propose no change.

> 
> 18. Section 12.1.3
>      Should this be moved out as a separate section, since, it is more
> than just implementation guidelines

This section is placed where it is as it provides information on why the
RTP session configuration does matter for QoS.

I propose no change.

> 
> 19. SSRC Collision
>      It is not clear what implementation guidelines that is being
> provided.  

With the clarification of the first bullet, one clear implementation
guideline is provided. In addition it motivates why it matters and also
what its limitations are. Both things worth considering.

I propose no change.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------