Re: [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02)

["Black, David" <[e-mail]>]

> The more difficult case is when an SSRC is sending video using different
> markings for RTP packets carrying the I- and P-frames. Should that SSRC then
> mark its RTCP packets like the RTP packets carrying I-frames, like the RTP
> packets carrying P-frames, or what?

Answering a question w/a question :-), how are those reports likely to be used?

For example, if the primary use of these reports is to adjust a variable rate
codec's sending rate, the P-frame info is probably more useful as indicative
of what's happening to the traffic that the network drops first when the going
gets rough (or whose delivery w/o loss indicates that a sending rate increase
may be reasonable), which suggests P-frame-like RTCP report marking.

Thanks,
--David


> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: Tuesday, August 26, 2014 12:19 PM
> To: Paul E. Jones
> Cc: Ben Campbell; Black, David; [e-mail]; [e-mail] WG; draft-ietf-
> [e-mail]
> Subject: Re: Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC:
> draft-ietf-dart-dscp-rtp-02)
> 
> On 26 Aug 2014, at 16:52, Paul E. Jones <[e-mail]> wrote:
> > Ben,
> >>>>>> Getting feedback to the sender is important, though. In an ideal world,
> I would argue that RTCP packets should be marked with whatever DSCP value will
> deliver RTCP packets in the most expedient way. Since we don't have an ideal
> world, I don't know which DSCP value that would be.
> >>>>>
> >>>>> Would the starting positions of "getting feedback is important, even of
> not for RTT estimates" and "we need RTCP for RTT estimates" likely land on the
> same guidance for DSCP values?
> >>>>>
> >>>>> The argument to send RTCP packets in the most expedient way sounds
> reasonable. I don't know if we need to recommend a particular DSCP, since we
> already have quite a bit of text on how DSCPs might (or might not) map into
> some predictable PHB treatment.
> >>>>
> >>>> Good question and valid point. Nowhere in the document do we recommend
> the use of a particular DSCP value for any particular thing, and we should not
> recommend a particular value for RTCP in this document. I'm just not sure what
> statements should be made.
> >>>>
> >>>> I suspect we can all agree that RTCP information is important. It's just
> the DSCP-related guidance that goes with that that is challenging.
> >>>
> >>> I don't agree that RTCP information should be sent as higher priority than
> the media. Ideally, it should be sent with the same priority as the media, so
> it can be used to sample the RTT. This RTT sample is independent of RMCAT.
> It's in base RTP specification, and so is something we need to support to the
> extent possible.
> >>>
> >>> Since not all the media sent by a single SSRC has the same marking, my
> suggestion would be that each SSRC mark the RTCP packets it sends with one of
> the same code points as it uses to mark the media. Since RTCP is somewhat
> important, it would make sense for each SSRC to mark the RTCP packets it sends
> using the highest priority code point it uses to mark the RTP media packets it
> sends.
> >>
> >> That makes sense to me. Paul, and others, do you agree with that last
> paragraph?
> >
> > I agree that the value should be one of the values used for media, but the
> challenge is specifying which DSCP value to use.  If audio is sent using EF,
> video as AF41, app sharing video as AF31, etc., which of these does the
> endpoint choose to use for RTCP?
> 
> Such an endpoint will have three SSRC values, and will mark the RTCP packets
> sent by each SSRC in the same way as the media packets sent by that SSRC. That
> is, the RTCP relating to the audio will be marked EF, the RTCP relating to the
> video will be marked AF41, and the RTCP relating to the application sharing
> video will be marked AF31. The RTCP packets for each stream are sent
> separately, so this case seems straight-forward.
> 
> The more difficult case is when an SSRC is sending video using different
> markings for RTP packets carrying the I- and P-frames. Should that SSRC then
> mark its RTCP packets like the RTP packets carrying I-frames, like the RTP
> packets carrying P-frames, or what?
> 
> Colin
> 
> 
> 
> 
> > Since DSCP values cannot be assumed to any particular PHB behavior in the
> network, that makes answering that question challenging.
> >
> > My personal preference in a voice/video conference would be to use the same
> marking as is used for those flows -- and I would use the same value for both
> voice and video.  However, if the app sharing video is considered more
> important by some applications, perhaps that's the value that should be used
> in those applications.
> >
> > I can accept the suggestion, leaving the specific selection as an
> implementation matter.  I do wish there was something more concrete so that
> two devices would always follow the same approach to selecting a value, but I
> doubt we can get agreement very quickly.
> >
> > Paul
> >
> 
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
>