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

[Colin Perkins <[e-mail]>]

One small comment inline, but in general I agree with Magnus’ response.
Colin


On 15 May 2014, at 15:12, Magnus Westerlund <[e-mail]> wrote:
> 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)

I’d prefer to keep this, since this issue has been a source of confusion in the past.

>> 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]
> ----------------------------------------------------------------------
> <AVPF vs AVP RTCP Intevals.pptx>_______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb



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