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

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

Makes sense - let me see if I can find time for one more edit this evening ...

Thanks, --David +++Sent from Blackberry

----- Original Message -----
From: Colin Perkins [mailto:[e-mail]]
Sent: Monday, September 01, 2014 07:10 AM
To: Ben Campbell <[e-mail]>
Cc: Harald Tveit Alvestrand <[e-mail]>; Black, David; [e-mail] <[e-mail]>
Subject: Re: [Dart] draft-dart-dscp-rtp - way forward

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/