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

From: "Black, David" <[email-masked]>
Date: Thu, 28 Aug 2014 14:12:05 -0400

Looking at the list discussion, I think I see enough info to produce a
-05 version of this draft that should address all the last call items.

Reminder - we had 6 WG LC open issues and work items:

[A] Work item: Gorry Fairhurst's item (1), a new Section 5.4 on "single
PHB/DSCP for a single TCP connection, SCTP association or DCCP connection" -
I need to write this text, and will try to do that over the weekend.

--> Done, as noted previously, this text wound up in section 5.1 of the
--> -04 draft, along with slimming down of the corresponding guideline in
--> section 6.  I haven't seen a note from Gorry indicating that he's
--> checked it, though.

[B] Open issue: PHBs and DSCPs for RTCP.  The RTCP guideline bullet cannot
be revised until this open issue is resolved on the list.  See:
	http://www.ietf.org/mail-archive/web/dart/current/msg00156.html

--> I think I see rough agreement that for RTCP SRs, the same DSCP should
--> be used as the RTP stream being reported on, and for RTCP RRs, the 
--> DSCP to use should be the one that would be used to send a similar
--> RTP stream.

--> Beyond that, when an AF class is used, the DSCP with least likelihood
--> of drop should be used, and for a single RTCP report on multiple RTP
--> streams for which different DSCPs apply, it's up to the RTCP
--> implementation to choose one.

--> There's enough text to write here, including mentioning that RTCP
--> feedback is not currently used for congestion control, that I think
--> this should be in a new section 5.4, along with a rewritten guideline
--> item in Section 6.  I hope to send draft text later today.

[C] Work item:  Request to Ben Campbell for "additional text on context
(WebRTC, clue and bundle) for the Introduction and Abstract, plus for a
better example in Section 4."

--> Done, text is in -04, with some minor edits coming in -05.

[D] Open issue: Question to Harald Alvestrand - Does CNAME need to be used
in section 2.2 text?  I hope not.

--> Closed via a small text deletion in section 2.1 of -04 draft.

[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.

[F] Open issue: Harald Alvestrand's concerns about the RTCP multi-stream
optimization text in section 5.2 .  I don't think there's a problem here,
but I'm not an expert on the RTCP technology involved, and Harald may not
agree.  This is a different RTCP issue than [B].

--> Not an issue - At least Colin Perkins and I believe the existing
--> DART draft text is fine, so I don't think there's anything that needs
--> to be done for this.

I'm about to vanish for 2.5 weeks of vacation w/little to no email access,
so my goal is to get the -05 version submitted either tomorrow or Saturday.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Colin Perkins <[email-masked]>
Date: Thu, 28 Aug 2014 19:22:52 +0100

> --> DSCP to use should be the one that would be used to send a similar

The distinction between RTCP SR and RR isn’t useful here. What you want to say is that an SSRC needs to use the same marking for the RTCP packets it sends as it uses for the RTP packets it sends. If it doesn’t send any RTP packets, it marks its RTCP packets with the marking it would use if it did send RTP.

> —> implementation to choose one.

No. An SSRC that uses different DSCPs in the RTP packets it sends needs to use the DCSP with the least likelihood of drop from that set when sending its RTCP packets. 

In both cases, the marking of the RTP packets you receive does not affect how you mark the RTCP packets you send. You chose the marking for your RTCP packets based on the marking of the RTP packet you send, not those you receive.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Ben Campbell <[email-masked]>
Date: Thu, 28 Aug 2014 14:33:45 -0500

> The distinction between RTCP SR and RR isn’t useful here. What you want to say is that an SSRC needs to use the same marking for the RTCP packets it sends as it uses for the RTP packets it sends. I…

That last bit concerns me a bit. Are we really asking an implementation to figure out how it would have done something it isn't going to do?

---

From: "Black, David" <[email-masked]>
Date: Thu, 28 Aug 2014 15:41:38 -0400

> > The distinction between RTCP SR and RR isn't useful here. What you want to
> say is that an SSRC needs to use the same marking for the RTCP packets it
> sends as it uses for the RTP packets it sends. If it doesn't send any RTP
> packets, it marks its RTCP packets with the marking it would use if it did
> send RTP.
> 
> That last bit concerns me a bit. Are we really asking an implementation to
> figure out how it would have done something it isn't going to do?

Yes, --David

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Thursday, August 28, 2014 3:34 PM
> To: Colin Perkins
> Cc: Black, David; [email-masked]
> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward
> 
> 
> > The distinction between RTCP SR and RR isn't useful here. What you want to
> say is that an SSRC needs to use the same marking for the RTCP packets it
> sends as it uses for the RTP packets it sends. If it doesn't send any RTP
> packets, it marks its RTCP packets with the marking it would use if it did
> send RTP.
> 
> That last bit concerns me a bit. Are we really asking an implementation to
> figure out how it would have done something it isn't going to do?

---

From: Ben Campbell <[email-masked]>
Date: Thu, 28 Aug 2014 14:44:01 -0500

(as chair)

> --> to share any further thoughts, so I don't think there's anything to be done

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?

---

From: Ben Campbell <[email-masked]>
Date: Thu, 28 Aug 2014 14:48:21 -0500

>> figure out how it would have done something it isn't going to do?

Maybe I'm not connecting the dots correctly, but what kind of media is it going to not send? Are we assuming the same as what it receives?

(Right now I am not sending audio, video, or interactive-holodeck-with-smell-o-vision).

---

From: "Black, David" <[email-masked]>
Date: Thu, 28 Aug 2014 16:12:51 -0400

> Maybe I'm not connecting the dots correctly, but what kind of media is it
> going to not send? Are we assuming the same as what it receives?

Seems reasonable to me.

Thanks,
--David

> Sent: Thursday, August 28, 2014 3:48 PM
> To: Black, David
> Cc: Colin Perkins; [email-masked]
> Maybe I'm not connecting the dots correctly, but what kind of media is it
> going to not send? Are we assuming the same as what it receives?
>

---

From: "Black, David" <[email-masked]>
Date: Thu, 28 Aug 2014 16:15:36 -0400

> 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

> Sent: Thursday, August 28, 2014 3:44 PM
> To: Black, David; Harald Tveit Alvestrand
> Cc: [email-masked]
> 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?
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 28 Aug 2014 15:25:05 -0500

Okay, works for me.

Thanks!

Ben.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 28 Aug 2014 21:27:01 +0100

On 28 Aug 2014, at 20:48, Ben Campbell <[email-masked]> wrote:
>>>> The distinction between RTCP SR and RR isn't useful here. What you want to say is that an SSRC needs to use the same marking for the RTCP packets it sends as it uses for the RTP packets it sends. If it doesn’t send any RTP packets, it marks its RTCP packets with the marking it would use if it did send RTP.
>>> 
>>> That last bit concerns me a bit. Are we really asking an implementation to figure out how it would have done something it isn’t going to do?
>> 
>> Yes, --David
> 

Yes, that’s how RTP works. 

-- 
Colin Perkins
http://csperkins.org/

---

From: "Black, David" <[email-masked]>
Date: Thu, 28 Aug 2014 16:29:07 -0400

I'll go add a sentence to explain that to the draft 5.4 text ...

Thanks,
--David

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Thursday, August 28, 2014 4:27 PM
> To: Ben Campbell
> >>>> The distinction between RTCP SR and RR isn't useful here. What you want
> to say is that an SSRC needs to use the same marking for the RTCP packets it
> Yes, that's how RTP works.
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 29 Aug 2014 12:48:41 +0200

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).

---

From: "Black, David" <[email-masked]>
Date: Fri, 29 Aug 2014 11:14:38 -0400

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.

Thanks,
--David

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Friday, August 29, 2014 6:49 AM
> To: Ben Campbell; Black, David
> Cc: [email-masked]
> >>>> --> to share any further thoughts, so I don't think there's anything to
> be
> >>> done
> >>>> --> about this now.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 29 Aug 2014 10:51:48 -0500

It would be nice if we could close on the multi-stream question really soon now. I don't think I see a consensus here so far.

Perhaps this is an area where we should punt and indicate it needs further study?

Thanks!

Ben.

On Aug 29, 2014, at 10:14 AM, Black, David <[email-masked]> wrote:

> _______________________________________________
> Dart mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dart

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 29 Aug 2014 17:52:11 +0200

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

---

From: Colin Perkins <[email-masked]>
Date: Fri, 29 Aug 2014 17:04:54 +0100

On 29 Aug 2014, at 16:52, Harald Alvestrand <[email-masked]> wrote:
>> 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.
> 

I was, but thinking again, I’m not so sure. 

> 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. 

-- 
Colin Perkins
http://csperkins.org/

---

From: "Black, David" <[email-masked]>
Date: Fri, 29 Aug 2014 14:23:17 -0400

If DSCP choice for the reduced number of reports is orthogonal to use of the RTCP multi-stream optimisation, then I think the DART draft paragraph on that optimisation can be removed.

Consideration of the DSCP that will be used to send the reports may be a consideration in selecting the SSRC that reports on behalf of the reporting group (as we've tied the DSCP for RTCP to the originating SSRC), but that's probably better addressed (if relevant) in the multi-stream optimisation draft.

Further comments?

Thanks, --David +++Sent from Blackberry

----- Original Message -----
From: Colin Perkins [mailto:[email-masked]]
Sent: Friday, August 29, 2014 12:04 PM
To: Harald Alvestrand <[email-masked]>
Cc: Black, David; Ben Campbell <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Dart] draft-dart-dscp-rtp - way forward

-- 
Colin Perkins
http://csperkins.org/

---

From: Ben Campbell <[email-masked]>
Date: Fri, 29 Aug 2014 13:28:42 -0500

> Consideration of the DSCP that will be used to send the reports may be a consideration in selecting the SSRC that reports on behalf of the reporting group (as we've tied the DSCP for RTCP to the or…

From the conversation so far, I agree.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 29 Aug 2014 21:29:14 +0200

> 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…
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.

---

From: "Black, David" <[email-masked]>
Date: Fri, 29 Aug 2014 16:09:43 -0400

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

> Sent: Friday, August 29, 2014 3:29 PM
> To: Colin Perkins
> Cc: Ben Campbell; Black, David; [email-masked]
> >>> 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.
> > I was, but thinking again, I'm not so sure.
> >
> > 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.
> >
> >

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 29 Aug 2014 22:14:07 +0200

> EWR isn't even close to what we're used to at IETF meetings :-).

Looks good to me!

-- 
Surveillance is pervasive. Go Dark.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 29 Aug 2014 15:16:58 -0500

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.

---

From: "Black, David" <[email-masked]>
Date: Fri, 29 Aug 2014 16:19:58 -0400

Correct!!

----- Original Message -----
From: Ben Campbell [mailto:[email-masked]]
Sent: Friday, August 29, 2014 04:16 PM
To: Black, David
Cc: Harald Tveit Alvestrand <[email-masked]>; Colin Perkins <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Dart] draft-dart-dscp-rtp - way forward

Thanks, David!

Thanks!

Ben.

---

From: Colin Perkins <[email-masked]>
Date: Fri, 29 Aug 2014 22:55:54 +0100

Without having seen the submitted version, this sounds okay.

-- 
Colin Perkins
http://csperkins.org/

> On 29 Aug 2014, at 21:16, Ben Campbell <[email-masked]> wrote:
> 
> Thanks, David!
>

---

From: Ben Campbell <[email-masked]>
Date: Sat, 30 Aug 2014 19:26:28 -0500

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.