Re: [Dart] draft-dart-dscp-rtp - way forward

[Harald Alvestrand <[e-mail]>]

This illustrates well the thought that media RTT is not a good concept - each media stream goes only one way....

On 1. september 2014 13:10:41 CEST, Colin Perkins <[e-mail]> wrote:
>Ben,
>
>The guidance looks fine to me, but the explanatory text in the last
>paragraph of Section 5.4 is perhaps not quite right. The text:
>
>   This guidance may result in different DSCP markings for RTP streams
>   and RTCP receiver reports about those RTP streams.  The resulting
>   variation in network QoS treatment by traffic direction could result
>   in unrepresentative round trip time (RTT) estimates that don't
>   correspond to consistent network QoS treatment in both directions.
>  RTCP receiver reports may be relatively infrequent (e.g., may be sent
>   only once per video frame rendered) and hence the resulting RTT
>   estimates are of limited utility for congestion control (although
>   they have other important uses, see [RFC3550]).  For this reason, it
>   is not important that RTCP receiver reports receive the same network
>   QoS treatment as the RTP stream or streams being reported on.
>
>suggests that the RTT estimate derived from RTCP will be
>unrepresentative, since it may not have consistent network QoS in each
>direction. However, since the RTP media packets can use different QoS
>in each direction, the RTCP also needs to do so, to be representative!
>If the media used different QoS markings for different directions and
>the RTCP used the same marking, the RTT estimate wouldn’t match that of
>the media. 
>
>I suggest the paragraph be changed to:
>
>   This guidance may result in different DSCP markings for RTP streams
>   and the RTCP packets reporting on those RTP streams.  The resulting
>   variation in network QoS treatment by traffic direction is necessary
> to get representative round trip time (RTT) estimates that correspond 
>to the media path RTT. RTCP receiver reports may be relatively
>infrequent 
>and hence the resulting RTT estimates are of limited utility for
>congestion 
>control (although they have other important uses, see [RFC3550]).  For
>this 
>reason, it is important that RTCP receiver reports sent by an SSRC
>receive 
>the same network QoS treatment as the RTP stream being sent by that
>SSRC.
>
>Colin
>
>
>
>
>On 31 Aug 2014, at 01:26, Ben Campbell <[e-mail]> wrote:
>> Colin and Harald,
>> 
>> I see David has submitted version 06. Can you verify that you are
>okay with the language in this version? 
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> On Aug 29, 2014, at 4:55 PM, Colin Perkins <[e-mail]> wrote:
>> 
>>> Without having seen the submitted version, this sounds okay.
>>> 
>>> -- 
>>> Colin Perkins
>>> http://csperkins.org/
>>> 
>>> 
>>> 
>>>> On 29 Aug 2014, at 21:16, Ben Campbell <[e-mail]> wrote:
>>>> 
>>>> Thanks, David!
>>>> 
>>>> Am I counting correctly that this would close the last substantive
>open issue? If so, and if Harald and Colin confirm they are okay with
>the change, we should be able to request publication for the upcoming
>version, correct?
>>>> 
>>>> (I see that Harald expressed support as I am typing this...)
>>>> 
>>>> Thanks!
>>>> 
>>>> Ben.
>>>> 
>>>>> On Aug 29, 2014, at 3:09 PM, Black, David <[e-mail]>
>wrote:
>>>>> 
>>>>> Ok, I see a range of views from skepticism to outright opposition
>...
>>>>> 
>>>>> I'll delete the paragraph and reference to the multi-stream
>optimization
>>>>> draft and submit the resulting -06 version w/a change note that
>any interaction
>>>>> of DiffServ and RTCP multi-stream optimization will be dealt with
>in the draft
>>>>> about the latter.
>>>>> 
>>>>> That submission won't happen tonight, as the network in the SAS
>Lounge in
>>>>> EWR isn't even close to what we're used to at IETF meetings :-).
>>>>> 
>>>>> Thanks,
>>>>> --David
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Harald Alvestrand [mailto:[e-mail]]
>>>>>> Sent: Friday, August 29, 2014 3:29 PM
>>>>>> To: Colin Perkins
>>>>>> Cc: Ben Campbell; Black, David; [e-mail]
>>>>>> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward
>>>>>> 
>>>>>>> On 08/29/2014 06:04 PM, Colin Perkins wrote:
>>>>>>>> On 29 Aug 2014, at 16:52, Harald Alvestrand
><[e-mail]> wrote:
>>>>>>>>> On 08/29/2014 05:14 PM, Black, David wrote:
>>>>>>>>> Harald,
>>>>>>>>> 
>>>>>>>>> I'm about to submit a -05 with the indication that the single
>DSCP
>>>>>> recommendation for SCTP and DCCP may be revised.  The RTCP
>multi-stream
>>>>>> optimisation text will still be in there with Colin's
>clarification about
>>>>>> "received" streams.  I'm about to vanish for about 3 weeks, but
>could put in a
>>>>>> revised -06 over the weekend if you can quickly convince Colin.
>>>>>>>> Explicitly pinging Colin - Colin, are you arguing that the
>sentence
>>>>>>>> 
>>>>>>>> RTCP multi-stream reporting optimizations for an RTP session
>>>>>>>> [I-D.ietf-avtcore-rtp-multi-stream-optimisation] assume that
>the RTP
>>>>>>>> streams involved experience the same packet loss behavior. 
>This
>>>>>>>> mechanism is highly inappropriate when the RTP streams involved
>use
>>>>>>>> different PHBs, even if those PHBs differ solely in drop
>precedence.
>>>>>>>> 
>>>>>>>> should stay in the draft?
>>>>>>> I was, but thinking again, I'm not so sure.
>>>>>>> 
>>>>>>>> I think this recommendation is wrong.
>>>>>>>> 
>>>>>>>> I can't find anything in your latest messages that speak to
>this particular
>>>>>> point.
>>>>>>>> You're one of the authors of -multi-stream, so you should be
>able to speak
>>>>>> clearly to the point.
>>>>>>>> 
>>>>>>>> Can you clarify?
>>>>>>> If I have several SSRCs, and receive several media streams, then
>provided
>>>>>> each of my SSRCs sees the exact same quality for each received
>stream, then  I
>>>>>> can use the multi-stream-optimisation to reduce the number of
>RTCP cross
>>>>>> reports I send. The multi-stream-optimisation draft says that
>already, and
>>>>>> it's not clear that the DART drafts needs to say anything further
>on the
>>>>>> topic.
>>>>>>> 
>>>>>>> Whether I use the same DSCP for all RTCP reports I send is, I
>think,
>>>>>> orthogonal to whether I use the multi-stream-optimisation. The
>dart draft
>>>>>> should possibly say that, but I'm not sure that's the sentence we
>have above.
>>>>>> I read the sentence above as saying flatly and unconditionally
>"don't
>>>>>> use multi-stream-optimization when the RTP streams have different
>PHBs"
>>>>>> - which means that if I want to use one PHB for audio and another
>PHB
>>>>>> for video, I can't use multi-stream-optimization.
>>>>>> 
>>>>>> I'd be sad if that was the case, *especially* if we can't figure
>out any
>>>>>> reason to make that recommendation.
>>>> 
>>> 
>>> _______________________________________________
>>> Dart mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dart
>> 
>
>
>
>-- 
>Colin Perkins
>http://csperkins.org/

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.