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

[Harald Alvestrand <[e-mail]>]

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 optimization 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 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?




>
> Thanks,
> --David
>
>> -----Original Message-----
>> From: Harald Alvestrand [mailto:[e-mail]]
>> Sent: Friday, August 29, 2014 6:49 AM
>> To: Ben Campbell; Black, David
>> Cc: [e-mail]
>> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward
>>
>> I think the text in -04 looks reasonable.
>>
>> I would like to do two things:
>>
>> - The justification for "single DSCP" in SCTP and DCCP is "we don't know
>> what will happen".
>> A logical consequence is that this recommendation might change as the
>> result of further study, so we might want to add near the bottom of
>> section 5 a sentence saying "This recommendation may be revisited if
>> experiments and analysis shows compelling reasons to change it."
>>
>> - I still think the ban against RTCP multi-stream reporting optimization
>> is completely wrong. The reports will correctly reflect the differing
>> packet loss behaviours of the incoming RTP streams, and that's all they
>> should be required to do.
>>
>> I regard the latter as somewhat important. The former is more a matter
>> of taste (if we're arguing based on ignorance, allow for the case where
>> ignorance becomes knowledge).
>>
>>
>> On 08/28/2014 10:25 PM, Ben Campbell wrote:
>>> Okay, works for me.
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>> On Aug 28, 2014, at 3:15 PM, Black, David <[e-mail]> wrote:
>>>
>>>>> If we think we can close this as not a real issue (or at least not an
>> issue we
>>>>> plan to address), but there's some risk it might come back up at IETF LC,
>> then
>>>>> that's fine. But if we are saying there is an open issue that needs
>> closure,
>>>>> but we can close it during IETF last call, then I have reservations. The
>>>>> version that goes to IETF LC should be one that the working group believes
>> to
>>>>> be as complete is it's going to get.
>>>> In private discussion, both Harald and I favored saying less (rather than
>> more)
>>>> about RMCAT in this DART draft.  For that reason I think "at least not
>>>> an issue we plan to address" is a valid characterization of this item.
>>>>
>>>> Thanks,
>>>> --David
>>>>
>>>>> -----Original Message-----
>>>>> From: Ben Campbell [mailto:[e-mail]]
>>>>> Sent: Thursday, August 28, 2014 3:44 PM
>>>>> To: Black, David; Harald Tveit Alvestrand
>>>>> Cc: [e-mail]
>>>>> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward
>>>>>
>>>>> (as chair)
>>>>>
>>>>> On Aug 28, 2014, at 1:12 PM, Black, David <[e-mail]> wrote:
>>>>>
>>>>>> [E] Open issue: Harald Alvestrand's concerns about "differential
>> treatment"
>>>>>> wrt Section 5.1 .  I don't completely understand these concerns, and
>> suspect
>>>>>> that they may require an email discussion across the DART and RMCAT WGs
>>>>>> to sort through.
>>>>>>
>>>>>> --> Deferred - Harald wanted to think about this, and I've seen nothing
>>>>>> --> further.  I'd suggest that IETF Last Call as an appropriate
>> opportunity
>>>>>> --> to share any further thoughts, so I don't think there's anything to
>> be
>>>>> done
>>>>>> --> about this now.
>>>>> I have mixed feelings on this.
>>>>>
>>>>> If we think we can close this as not a real issue (or at least not an
>> issue we
>>>>> plan to address), but there's some risk it might come back up at IETF LC,
>> then
>>>>> that's fine. But if we are saying there is an open issue that needs
>> closure,
>>>>> but we can close it during IETF last call, then I have reservations. The
>>>>> version that goes to IETF LC should be one that the working group believes
>> to
>>>>> be as complete is it's going to get.
>>>>>
>>>>> David, thoughts?
>>>>>
>>>>> Harald, do you care to comment further?