Re: [AVTCORE] WGLC review on draft-ietf-avtcore-multi-media-rtp-session-09

["Asveren, Tolga" <[e-mail]>]

Inline...

Thanks,
Tolga

> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: Thursday, September 10, 2015 1:57 PM
> To: Asveren, Tolga <[e-mail]>
> Cc: [e-mail]; Ali Begen <[e-mail]>
> Subject: Re: [AVTCORE] WGLC review on draft-ietf-avtcore-multi-media-rtp-
> session-09
> 
> On 10 Sep 2015, at 17:55, Asveren, Tolga <[e-mail]> wrote:
> >>> The RTCP timing rules in RFC 3550 don't support different reporting
> >>> intervals for different SSRCs (other than a sender/receiver split),
> >>> and doing so runs a risk of causing inappropriate RTCP timeouts. We
> >>> could add a reference to RFC
> >>> 3550 here, if it helps?
> >> [TOLGA] Can't this be changed? On a high level, aren't we talking about
> two different RTCP streams here? Why should their timing be aligned in any
> way?
> >
> > Their timing isn’t aligned, they merely use the same base RTCP reporting
> interval, before randomisation, and modulo the difference between sender
> and receiver bandwidth allocation. This is the usual RFC 3550 RTCP timing
> rules. If you want different reporting intervals, you need to use separate RTP
> sessions.
> > [TOLGA] I was also referring to reporting timing but admittedly not being
> clear. But then again, why should their timing be the same? Is there a
> technical justification or "just" because RFC3550 (which probably did not
> consider the use case defined/explained in this draft as it was not defined
> yet) says so?
> 
> The technical justification is as I said above: you get inappropriate timeouts,
> because the algorithm is based on all SSRCs using the same base reporting
> interval.
[TOLGA] But that is exactly what I am asking, why can’t that be changed so that algorithm for different SSRCs are executed independently if multiple streams are multiplexed?
> 
> Colin
> 
> 
> 
> 
> 
> > Thanks,
> > Tolga
> >
> >> -----Original Message-----
> >> From: Colin Perkins [mailto:[e-mail]]
> >> Sent: Thursday, September 10, 2015 6:53 AM
> >> To: Asveren, Tolga <[e-mail]>
> >> Cc: [e-mail]; Ali Begen <[e-mail]>
> >> Subject: Re: [AVTCORE] WGLC review on
> >> draft-ietf-avtcore-multi-media-rtp-
> >> session-09
> >>
> >>>> On 10 Sep 2015, at 11:27, Asveren, Tolga <[e-mail]>
> >>> wrote:
> >>>
> >>> Please see inline for questions/answers/comments.
> >>>
> >>> Thanks,
> >>> Tolga
> >>>
> >>>> -----Original Message-----
> >>>> From: Colin Perkins [mailto:[e-mail]]
> >>>> Sent: Monday, September 07, 2015 7:35 AM
> >>>> To: Asveren, Tolga <[e-mail]>
> >>>> Cc: [e-mail]; Ali Begen <[e-mail]>
> >>>> Subject: Re: [AVTCORE] WGLC review on
> >>>> draft-ietf-avtcore-multi-media-rtp-
> >>>> session-09
> >>>>
> >>>> Hi,
> >>>>
> >>>> Thanks for the review; some responses inline.
> >>>>
> >>>> On 6 Sep 2015, at 14:24, Asveren, Tolga <[e-mail]>
> >> wrote:
> >>>>> I did not monitor the progress of this draft over its lifetime, so
> >>>>> this is more of an "outsider's review" (which probably is useful
> >>>>> in its own right)
> >>>>>
> >>>>> i- 2. Terminology
> >>>>> "Media Type:  The general type of media data used by a real-time
> >>>>>    application.  The media type corresponds to the value used in the
> >>>>>    <media> field of an SDP m= line.  The media types defined at the
> >>>>>    time of this writing are "audio", "video", "text", "application",
> >>>>>    and "message"."
> >>>>>
> >>>>> - It could be good to provide a reference to the corresponding
> >>>>> IANA
> >> registry.
> >>>>> - I know it is not very common but still defined/possibly used, is
> >>>>> there a
> >> specific reason not to include “image” (e.g., image/t38, image/g3fax)
> >> in this list?
> >>>>
> >>>> I copied the list from draft-ietf-mmusic-rfc4566bis-15, which
> >>>> doesn't mention "image". I agree we should mention it, as should
> 4566bis.
> >>>> (I've cc'd Ali, for comment).
> >>>>
> >>>>> ii- 3.  Background and Motivation
> >>>>> In general, this section seems trying to do a “hard sell", which
> >>>>> IMHO can
> >> be softened up a little bit.
> >>>>>
> >>>>> - "However, we note that many RTP-using application don't use
> >>>>> network  QoS features, and don't expect or desire any separation
> >>>>> in network  treatment of their media packets, independent of
> >>>>> whether they are  audio, video or text.  When an application has
> >>>>> no such desire, it  doesn't need to provide a transport flow
> >>>>> structure that simplifies  flow based QoS."
> >>>>> This really depends on the environment and deployment model. In
> >>>>> addition to that, providing QoS with DiffServ is still possible
> >>>>> when multiple types of media are sent in a single RTP session as
> >>>>> explained in draft-ietf-dart-dscp-rtp (which is already referenced
> >>>>> by this
> >>>>> draft)
> >>>>
> >>>> It's not clear what change you want here. Do you have a suggestion
> >>>> for how to update the text?
> >>> [TOLGA] Maybe just taking out QoS related part?
> >>
> >> Since RFC 3550 explicitly calls out QoS as a reason for sending
> >> multiple media streams on different transport layer flows, I don’t think
> we can do this.
> >>
> >>>>> -  "1.  increased delay to establish a complete session, since each of
> >>>>>     the transport layer flows needs to be negotiated and established;"
> >>>>> At least negotiation part can happen in parallel. And when
> >>>>> multiple
> >> streams use the same RTP session, isn’t there still a need to
> >> negotiate different SSRC values, one per stream? A reference to
> >> RFC5576 could be useful as well.
> >>>>
> >>>> Negotiation can only happen in parallel to a certain extent, before
> >>>> the amount of STUN traffic causes congestion. The SSRCs also don't
> >>>> necessarily have to be negotiated in advance for either model.
> >>> [TOLGA] It could be useful to provide more information about how
> >> demultiplexing based on SSRC would work when multiple streams are
> >> sent in the same RTP session. Isn't there inherently a need to
> >> associate a stream with a particular SSRC? How is this done? Just a
> >> description of that, maybe in Section 5.2. so that the logic is
> >> obvious to people (particularly to first-time readers).
> >>
> >> RTP doesn’t have a requirement to associate a stream with an SSRC.
> >> Certain classes of application might have such a requirement, but
> >> that’s a signalling issue, and so not something for this draft (it’s
> >> something for BUNDLE, or similar, to specify).
> >>
> >>>>> iii- 5.3.  Per-SSRC Media Type Restrictions This section provides
> >>>>> the
> >> justification why different SSRC but be used for audio and video
> >> streams but not really why a SSRC can’t be re-used for streams of
> >> different type. It would be good to cover that aspect as well.
> >>>>
> >>>> Sorry, I'm not sure what you're asking here. Can you rephrase?
> >>> [TOLGA] Mea culpa, I think 5.3 already explains why the same SSRC
> >>> can't be
> >> re-used for streams of different type:
> >>> "The payload type will inform a receiver which  media type the SSRC
> >>> is being used for.  Thus the payload type MUST be  unique across all
> >>> of the payload configurations independent of media  type that is
> >>> used in the RTP session."
> >>> I guess this section provides the justification. Please correct me
> >>> if I am
> >> wrong.
> >>
> >> The 2nd and 3rd paragraphs of Section 5.3 explain why an SSRC can’t
> >> simultaneously be used for audio and video streams.
> >>
> >> An SSRC cannot start using audio and then switch to using video,
> >> since that would require a change in RTP timestamp rate (which RFC
> >> 7160 explains doesn’t work). However, an SSRC can send audio then
> >> leave the session (by sending an RTCP BYE, or stopping sending RTP
> >> and RTCP for long enough that it times out), then a new source can
> >> start with the same SSRC number sending video; this doesn’t cause
> >> confusion because the audio SSRC has gone before the video SSRC starts.
> >>
> >>
> >>>>> iv- 4.  Applicability
> >>>>> "Compatible RTCP Behaviour:  The RTCP timing rules enforce a single
> >>>>>    RTCP reporting interval for all participants in an RTP session.
> >>>>>    Flows with very different media sending rate or RTCP feedback
> >>>>>    requirements cannot be multiplexed together, since this leads to
> >>>>>    either excessive or insufficient RTCP for some flows, depending
> >>>>>    how the RTCP session bandwidth, and hence reporting interval, is
> >>>>>    configured."
> >>>>> This part IMHO requires more justification. Why is it not possible
> >>>>> to send
> >> RTCP in different rates for different flows? Some RTCP packets could
> >> have reports pertaining to a single stream whereas the other ones
> >> (when timing for reports for different streams overlaps or is
> >> sufficiently close enough) for multiple streams. Aggregate RTCP
> >> bandwidth need shouldn’t be a constraining factor just because a
> >> single transport flow is used AFAICS. If that is not the case, it really could
> be useful to explain why.
> >>>>
> >>>> The RTCP timing rules in RFC 3550 don't support different reporting
> >>>> intervals for different SSRCs (other than a sender/receiver split),
> >>>> and doing so runs a risk of causing inappropriate RTCP timeouts. We
> >>>> could add a reference to RFC
> >>>> 3550 here, if it helps?
> >>> [TOLGA] Can't this be changed? On a high level, aren't we talking
> >>> about two
> >> different RTCP streams here? Why should their timing be aligned in any
> way?
> >>
> >> Their timing isn’t aligned, they merely use the same base RTCP
> >> reporting interval, before randomisation, and modulo the difference
> >> between sender and receiver bandwidth allocation. This is the usual
> >> RFC 3550 RTCP timing rules. If you want different reporting
> >> intervals, you need to use separate RTP sessions.
> >>
> >>>>> v- 7.  Signalling
> >>>>> "When using SDP signalling, the BUNDLE extension
> >>>>> [I-D.ietf-mmusic-sdp-bundle-negotiation] is used to signal RTP
> >>>>> sessions containing multiple media types."
> >>>>> It could be a good idea to reference relevant sections as the
> >>>>> bundle-draft
> >>>> has some irrelevant aspects (arguably which even could be confusing
> >>>> in the context of this specification).
> >>>>
> >>>> Can you be specific on how BUNDLE should be referenced?
> >>> [TOLGA] Maybe just specifying which sections are relevant and which
> >>> are
> >> not, e.g. "14. RTP/RTCP extensions for identification-tag transport"
> >> in draft- ietf-mmusic-sdp-bundle-negotiation-23.txt, is this part
> >> relevant to  draft-ietf- avtcore-multi-media-rtp-session-09?
> >>
> >> This is to address the stream identification issue you raise above.
> >>
> >> --
> >> Colin Perkins
> >> https://csperkins.org/
> >