Subject: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02

From: "Black, David" <[email-masked]>
Date: Fri, 22 Aug 2014 16:12:11 -0400

Hi Colin,

I've picked up your changes (including RTCWEB -> WebRTC globally)
in my working draft, with two exceptions:

(1) Items 3 and 4 in the list of what can be multiplexed.

I don't think you suggested any changes to these two items, but
they need significant attention for other reasons:

- Ben's comment that item 3 ought to focus on the WebRTC data channel
- STUN doesn't encapsulate WebRTC traffic (TURN does).

I plan to merge these items 3 and 4 as part of revising them, and
intend to move the topic of TURN encapsulation out to be discussed
elsewhere, as it's independent of multiplexing.  I'll propose
specific text in a separate message.

(2) PHBs and DSCPs for RTCP.

I'm not sure what to say about this, as it looks like I need to set
off a discussion (debate?) between you and my co-author, Paul Jones.  

Colin (from WGLC comments):

> Rather, within a single RTP session there are RTCP packets sent
> that give information about the RTP streams that are being sent, and that
> report on the reception quality of RTP streams being received. Using a single
> PHB and DSCP for all RTCP packets within an RTP session might make sense, but
> it's important to note that one role of RTCP is to provide an estimate of the
> round-trip time seen by the media, so the PHB/DSCP will have to be chosen with
> care to avoid biasing that estimate too much.

Paul (from shortly after the Toronto meeting:

> During the meeting, there was discussion of marking RTCP packets.  Some
> notes I received on this topic suggested that it was proposed that RTCP
> should be marked the same as for RTP.  The argument was that this is used
> for RTT calculations.  If that is what was said, I'd like to state my
> disagreement. :-)
> 
> The forward and reverse paths are not necessarily the same and there is
> nothing one should assume about the reverse path to provide guidance about
> the forward path (or vice versa).  As perhaps a gross example, I have the
> ability to download far faster on my home Internet connection than I can
> upload.  Other important traffic characteristics differ in each direction.
>  
> Further, an RTCP packet might provide information related to several different
> RTP packets.  I certainly would not want to see one RTCP packet per RTP packet.

I'll watch where that discussion goes before proposing text.

Thanks,
--David

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Monday, August 18, 2014 11:18 AM
> To: [email-masked]
> Cc: [email-masked] WG; Ben Campbell; [email-masked]
> Subject: Re: [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02
> 
> Hi,
> 
> [I'm not on the DART list, so please cc me in replies]
> 
> This draft looks good overall, but I did have some comments, primarily about
> the discussion of RTP multiplexing.
> 
> The four bullet points in Section 2.1 that follow "The RTCWEB protocol suit
> encompasses a number of forms of multiplexing" seem to confuse RTP sessions,
> RTCP, and transport-layer flows. I suggest they be changed to:
> 
> >    The RTP streams that comprise a WebRTC session can be multiplexed
> >    together in a number of ways:
> >
> >    1.  Individual source streams are carried in one or more individual
> >        RTP streams. These RTP streams can be multiplexed onto a single
> >        transport-layer flow or sent as separate transport-layer flows.
> >        This memo only considers the case where the RTP streams are to be
> >        multiplexed onto a single transport-layer flow, forming a single
> >        RTP session;
> >
> >    2.  The RTP Control Protocol (RTCP) [RFC3550] may be multiplexed onto
> >        the same transport-layer flow as the RTP stream with which it is
> >        associated, as described in [RFC5761], or it may be sent on a
> >        separate transport-layer flow;
> >
> >    3.  The RTP and RTCP traffic can be multiplexed with other protocols
> >        via UDP encapsulation over a common pair of UDP ports as described
> >        in [RFC5764] as updated by
> >        [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]; and
> >
> >    4.  The data may be further encapsulated via STUN [RFC5389] and TURN
> >        [RFC5766] for NAT (Network Address Translator) traversal.
> 
> In the following paragraph (penultimate paragraph in Section 2.1), I suggest
> changing "unidirectional UDP packet flow" to "transport-layer flow" since it
> will not be unidirectional (since RTCP also flows in the reverse direction),
> and might not use UDP.
> 
> In the first paragraph of section 2.2, I suggest changing "multiplexed over
> RTP sessions" to "multiplexed in a single RTP session" and "multiplexing of
> source streams in RTP sessions" to "multiplexing of source streams in a single
> RTP session".
> 
> In Section 6, the second bullet point refers to "an RTCP session". There is no
> such thing. Rather, within a single RTP session there are RTCP packets sent
> that give information about the RTP streams that are being sent, and that
> report on the reception quality of RTP streams being received. Using a single
> PHB and DSCP for all RTCP packets within an RTP session might make sense, but
> it's important to note that one role of RTCP is to provide an estimate of the
> round-trip time seen by the media, so the PHB/DSCP will have to be chosen with
> care to avoid biasing that estimate too much.
> 
> Editorial: the protocol is called WebRTC, but the working group is RTCWEB.
> Accordingly, I think all instances of "RTCWEB" in this draft need to change to
> "WebRTC".
> 
> Cheers,
> Colin
> 
> 
> 
> 
> 
> On 9 Aug 2014, at 19:48, Ben Campbell <[email-masked]> wrote:
> > Hi,
> >
> > The DART working group has started a last call for draft-ietf-dart-dscp-rtp-
> 02, ending on August 22. This informational draft describes considerations for
> the use of DiffServ code points in situations where one multiplexes multiple
> RTP packet streams, and potentially other protocol streams, that share the
> same 5-tuple.
> >
> > Since this draft is likely of interest to several working groups, I would
> like to solicit additional reviews from participants of TSVWG, AVTCORE,
> MMUSIC, CLUE, RTCWEB, and RMCAT. Please send any feedback (including feedback
> to the effect of "this is ready to progress") to the DART working group
> mailing list.
> >
> > Thanks!
> >
> > Ben.
> >
> > Begin forwarded message:
> >
> >> Resent-From: [email-masked]
> >> From: Ben Campbell <[email-masked]>
> >> Subject: WGLC: draft-ietf-dart-dscp-rtp-02
> >> Date: August 9, 2014 at 12:50:16 PM CDT
> >> Resent-To: [email-masked], [email-masked], [email-masked]
> >> To: [email-masked]
> >> Cc: [email-masked], [email-masked],
> Richard Barnes <[email-masked]>
> >>
> >> This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. It's
> available on the data tracker at the following URL:
> >>
> >> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/
> >>
> >> The WGLC will conclude on 22 August, 2014. Please send your comments to the
> authors and the DART mailing list. If you've reviewed it and think it's good
> to go, please say so.
> >>
> >> Thanks!
> >>
> >> Ben.
> >>
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 25 Aug 2014 12:19:28 +0100

Hi,

> specific text in a separate message.

That’s fine.

> I'll watch where that discussion goes before proposing text.

One of the uses of RTCP is certainly to estimate the round-trip time, as described in Section 6.4.1 (page 41) of RFC 3550. The DSCP marking used for RTCP does need to take this use into account. Ideally, this would mean RTCP packets were marked the same as the corresponding RTP packets, as I suggested in the meeting. However, Paul is correct that this only works when all RTP packets have the same marking.

Accordingly, I’m not sure what the right marking is for RTCP. One approach might be to say that an SSRC that sends RTP packets with different marking should use marking with the highest(lowest?) precedence of those is uses for RTCP, so the RTT estimate calculated from RTCP is representative of some RTP packets. I’m not sure that using a single DSCP for all RTCP packets would achieve that.

Colin

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 25 Aug 2014 13:12:01 -0500

> Accordingly, I’m not sure what the right marking is for RTCP. One approach might be to say that an SSRC that sends RTP packets with different marking should use marking with the highest(lowest?) pr…

Can this working group reasonably answer this question? If not, we could list it as something implementors need to think about, and note that we do not have generic guidance.

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 25 Aug 2014 19:52:08 +0000

Ben, Colin,

On (2) below, it might be a challenge to get agreement quickly, but it 
might be nice if we could.  As this work relates to RMCAT, determining 
one-way delay or changes thereto will likely prove important.  In 
general, I would expect perceived quality to be important and conveying 
quality metrics and/or providing feedback to the sender so that 
perceived quality improves (in whatever form) will be important.  I'm 
suspicious of use of any RTT calculation for any mechanism that might be 
used to improve QoE.

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.

There are several options we could consider:
* Mark all RTCP packets as CS0
* Mark RTCP packets using a locally-defined "highest priority" marking
* Mark RTCP packets the same as media flow for the first (active) SDP 
line (thus, if audio is the first m= line in SDP and that flow is 
active, all RTCP packets will be marked the same as audio)
* Specify a value for all RTCP packets irrespective of any value used in 
RTP flows

I think the right folks on the thread and on the list are present to 
help make that choice.  We just need to decide if that is something we 
want to specify.

Paul

------ Original Message ------
From: "Ben Campbell" <[email-masked]>
To: "Colin Perkins" <[email-masked]>
Cc: "Black, David" <[email-masked]>; "[email-masked]" 
<[email-masked]>; "[email-masked] WG" <[email-masked]>; "Paul E. Jones 
([email-masked])" <[email-masked]>; 
"[email-masked]" 
<[email-masked]>
Sent: 8/25/2014 2:12:01 PM
Subject: Re: [Dart] Colin Perkins comments - WGLC: 
draft-ietf-dart-dscp-rtp-02

>>  One of the uses of RTCP is certainly to estimate the round-trip time, 
>>as described in Section 6.4.1 (page 41) of RFC 3550. The DSCP marking 
>>used for RTCP does need to take this use into account. Ideally, this 
>>would mean RTCP packets were marked the same as the corresponding RTP 
>>packets, as I suggested in the meeting. However, Paul is correct that 
>>this only works when all RTP packets have the same marking.
>>
>>  Accordingly, I’m not sure what the right marking is for RTCP. One 
>>approach might be to say that an SSRC that sends RTP packets with 
>>different marking should use marking with the highest(lowest?) 
>>precedence of those is uses for RTCP, so the RTT estimate calculated 
>>from RTCP is representative of some RTP packets. I’m not sure that 
>>using a single DSCP for all RTCP packets would achieve that.
>
>Can this working group reasonably answer this question? If not, we 
>could list it as something implementors need to think about, and note 
>that we do not have generic guidance.
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 25 Aug 2014 15:12:04 -0500

Our charter is not to improve QoS or solve congestion issues. It's just to give guidance on DSCP choices for multiplexed media. So I think the question becomes, has RMCAT made decisions (or looks very likely to make decisions) to use RTCP in a way that would be impacted by our DSCP recommendations?

On Aug 25, 2014, at 2:52 PM, Paul E. Jones <[email-masked]> wrote:

> Ben, Colin,
> 
> On (2) below, it might be a challenge to get agreement quickly, but it might be nice if we could.  As this work relates to RMCAT, determining one-way delay or changes thereto will likely prove important.  In general, I would expect perceived quality to be important and conveying quality metrics and/or providing feedback to the sender so that perceived quality improves (in whatever form) will be important.  I'm suspicious of use of any RTT calculation for any mechanism that might be used to improve QoE.
> 

If so, then we should document the potential impact. If _not_, then it seems to me the best we could do is mention that RTCP treatments may or may not have an impact on RTT estimates, and that the implementer should think about it.

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

> * Mark RTCP packets the same as media flow for the first (active) SDP line (thus, if audio is the first m= line in SDP and that flow is active, all RTCP packets will be marked the same as audio)
> * Specify a value for all RTCP packets irrespective of any value used in RTP flows
> 
> I think the right folks on the thread and on the list are present to help make that choice.  We just need to decide if that is something we want to specify.
> 
> Paul
> 
> Cc: "Black, David" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked] WG" <[email-masked]>; "Paul E. Jones ([email-masked])" <[email-masked]>; "[email-masked]" <[email-masked]>
> Subject: Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02
> 
>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 25 Aug 2014 21:59:22 +0000

Ben,

>Our charter is not to improve QoS or solve congestion issues. It's just 
>to give guidance on DSCP choices for multiplexed media. So I think the 
>question becomes, has RMCAT made decisions (or looks very likely to 
>make decisions) to use RTCP in a way that would be impacted by our DSCP 
>recommendations?

I'm not aware of whether such a decision has been made.

>>  Ben, Colin,
>>
>>  On (2) below, it might be a challenge to get agreement quickly, but 
>>it might be nice if we could. As this work relates to RMCAT, 
>>determining one-way delay or changes thereto will likely prove 
>>important. In general, I would expect perceived quality to be 
>>important and conveying quality metrics and/or providing feedback to 
>>the sender so that perceived quality improves (in whatever form) will 
>>be important. I'm suspicious of use of any RTT calculation for any 
>>mechanism that might be used to improve QoE.
>>
>
>If so, then we should document the potential impact. If _not_, then it 
>seems to me the best we could do is mention that RTCP treatments may or 
>may not have an impact on RTT estimates, and that the implementer 
>should think about it.

If accurate RTT measurements could be made, they could be useful.  The 
problem is that in some environments, we know that RTTs will not be 
accurate.  Sometimes they are, of course.

We could have some text as you suggest, but I would personally prefer we 
not encourage use of RTT values for any particular purpose. :-)

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

David? :-)

Paul

---

From: Colin Perkins <[email-masked]>
Date: Tue, 26 Aug 2014 11:17:01 +0100

On 25 Aug 2014, at 22:59, Paul E. Jones <[email-masked]> wrote:
> I’m not aware of whether such a decision has been made.

I don’t believe RMCAT has considered this issue.

> If accurate RTT measurements could be made, they could be useful.  The problem is that in some environments, we know that RTTs will not be accurate.  Sometimes they are, of course.
> 
> We could have some text as you suggest, but I would personally prefer we not encourage use of RTT values for any particular purpose. :-)
> 
> 
> 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.

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 26 Aug 2014 10:21:37 +0000

On Aug 26, 2014, at 1:17 PM, Colin Perkins <[email-masked]> wrote:

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

Agreed. RTCP should not have any higher priority than RTP media. First, you don't want RTCP traffic to cause damage to RTP traffic. Second, not being in the same class, RTCP reported data wont reflect the reality for RTP traffic. If you want protection for RTCP packets, use redundancy or other techniques within the bounds allowed by 3550.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 26 Aug 2014 09:16:11 -0500

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

That makes sense to me. Paul, and others, do you agree with that last paragraph?

/Ben

---

From: "Black, David" <[email-masked]>
Date: Tue, 26 Aug 2014 11:39:43 -0400

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

<editor hat off>

Sure, when there's a notion of priority or importance.  There won't always
be one (e.g., is CS2 higher priority than AF2x?  That depends ...).  OTOH,
we don't need to say much here, e.g., the class selector codepoints (CSx)
are ordered, and adding a pointer to draft-ietf-tsvwg-rtcweb-qos will be
helpful.

</editor hat off>

Turning to the other RTCP issue, [F] on multi-stream optimization, I wonder
whether we inadvertently framed that issue backwards.  Given the above, a
single RTCP report on multiple RTP streams that use rather different DSCPs
may not result in representative RTT values for all of the streams, because
the report has to be sent with one DSCP.  If that outcome is a problem,
one should send separate RTCP reports (duh!). 

That statement seems valuable to make and can be made with a citation of
RFC 3530, as opposed to the multi-stream optimization draft.

Harald and Colin - what do you think?

Thanks,
--David

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, August 26, 2014 10:16 AM
> To: Colin Perkins; Paul E. Jones
> Cc: Black, David; [email-masked]; [email-masked] WG; draft-ietf-dart-dscp-
> [email-masked]
> Subject: Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC:
> draft-ietf-dart-dscp-rtp-02)
> 
> 
> >>>> 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.
> >>>
> not for RTT estimates" and "we need RTCP for RTT estimates" likely land on the
> same guidance for DSCP values?
> >>>
> 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.
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 26 Aug 2014 15:52:57 +0000

Ben,

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

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?

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 26 Aug 2014 16:53:34 +0100

> one should send separate RTCP reports (duh!). 

Each reporting SSRC sends a separate RTCP report block for each SSRC it receives, so this is not a problem. The question is what marking an SSRC uses for the RTCP packets it sends, given that it uses several different markings for the RTP media packets it sends. 

> Harald and Colin - what do you think?

The discussion of the multi-stream-optimisation draft is a separate issue, and is correct as it is.

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 26 Aug 2014 17:19:02 +0100

On 26 Aug 2014, at 16:52, Paul E. Jones <[email-masked]> wrote:
> 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/

---

From: "Black, David" <[email-masked]>
Date: Tue, 26 Aug 2014 12:38:22 -0400

> 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

> Sent: Tuesday, August 26, 2014 12:19 PM
> To: Paul E. Jones
> Cc: Ben Campbell; Black, David; [email-masked]; [email-masked] WG; draft-ietf-
> [email-masked]
> Subject: Re: Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC:
> I would argue that RTCP packets should be marked with whatever DSCP value will
> 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 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.
> >
> 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/
> 
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 27 Aug 2014 05:17:38 +0000

Colin,

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

I'm a little confused here.  These are separate SSRCs, but all part of a 
single RTP session.  So, wouldn't the three SSRCs be reported in 
different report blocks in the sender report?

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

For this, I would argue it should be whatever DSCP that has the lower 
drop precedence (in the case of assured forwarding).  Otherwise, it 
should be the same as the media, I'd think.

Paul

---

From: Colin Perkins <[email-masked]>
Date: Wed, 27 Aug 2014 09:00:35 +0100

On 27 Aug 2014, at 06:17, Paul E. Jones <[email-masked]> wrote:
> I'm a little confused here.  These are separate SSRCs, but all part of a single RTP session.  So, wouldn’t the three SSRCs be reported in different report blocks in the sender report?

Each of the SSRCs will report on all the others, unless the rtp-multi-stream-optimisation draft is used, but so what? 

> For this, I would argue it should be whatever DSCP that has the lower drop precedence (in the case of assured forwarding).  Otherwise, it should be the same as the media, I'd think.

You mean the RTCP for each SSRC should use the DSCP with the lowest drop preference of those used for the media sent by that SSRC?

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 27 Aug 2014 17:00:37 +0100

> may be reasonable), which suggests P-frame-like RTCP report marking.

I doubt the RTT estimate derived from RTCP is used for congestion control, since it’s too infrequent to get insight into the dynamics. It’s for user experience reporting, maybe rough clustering of receivers, that sort of thing. 

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

---

From: Michael Welzl <[email-masked]>
Date: Wed, 27 Aug 2014 20:39:27 +0200

> I doubt the RTT estimate derived from RTCP is used for congestion control, since it’s too infrequent to get insight into the dynamics. It’s for user experience reporting, maybe rough clustering of…

I'd agree if I didn't have the impression, in RMCAT, that nothing but RTP / RTCP is allowed?!  So can we send extra packets to probe for the RTT?

Cheers,
Michael

---

From: Colin Perkins <[email-masked]>
Date: Wed, 27 Aug 2014 19:42:38 +0100

> I'd agree if I didn't have the impression, in RMCAT, that nothing but RTP / RTCP is allowed?!  So can we send extra packets to probe for the RTT?

I’d expect RMCAT will probe the one-way delay variation by measuring the arrival times of RTP packets, and report that in RTCP once per video frame (or so). That would give a much more accurate measurement than a single-packet sample of the RTT derived from RTCP, and would still allow per-frame adaptation.

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

---

From: Michael Welzl <[email-masked]>
Date: Wed, 27 Aug 2014 20:47:03 +0200

> I’d expect RMCAT will probe the one-way delay variation by measuring the arrival times of RTP packets, and report that in RTCP once per video frame (or so). That would give a much more accurate mea…

I agree that this is a useful signal to use - but I think you still need a rough idea of the RTT to be able to interoperate with TCP, else you may cause TCP to go into RTOs and be ignorant of that. But this could perhaps be a more coarse signal - maybe that's okay. I think this is reasonable.

I wonder if your RTCP draft in RMCAT should clarify this?  (sorry if it does already, didn't check)

Cheers,
Michael

---

From: Colin Perkins <[email-masked]>
Date: Wed, 27 Aug 2014 19:50:22 +0100

> I agree that this is a useful signal to use - but I think you still need a rough idea of the RTT to be able to interoperate with TCP, else you may cause TCP to go into RTOs and be ignorant of that.…

You have the RTT estimate, irrespective of the other information you include along with the regular RTCP packets, although it’s relatively infrequent and coarse-grained.

> I wonder if your RTCP draft in RMCAT should clarify this?  (sorry if it does already, didn’t check)

It probably should talk about this, I agree.

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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 27 Aug 2014 14:46:21 -0500

Hi,

Where are we with this discussion? Are there conclusions buried in there somewhere?

Thanks!

Ben.

On Aug 27, 2014, at 1:50 PM, Colin Perkins <[email-masked]> wrote:

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

---

From: Michael Welzl <[email-masked]>
Date: Wed, 27 Aug 2014 22:45:03 +0200

I don't know the beginning of this but I can help go up the stack:

for the short dialogue between Colin and me, the conclusion is: Colin is right. RTCP probably won't be used by congestion control to estimate the RTT.

Cheers,
Michael

---

From: Ben Campbell <[email-masked]>
Date: Wed, 27 Aug 2014 15:48:37 -0500

> for the short dialogue between Colin and me, the conclusion is: Colin is right. RTCP probably won't be used by congestion control to estimate the RTT.

Thanks, Michael, I think that fits with some earlier conversations as well.

Colin and Paul (and David):

Are we converging on what guidance to put into the DART draft?

Thanks!

Ben.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 27 Aug 2014 21:41:53 +0000

Colin

>>>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.
>>
>>  I'm a little confused here. These are separate SSRCs, but all part of 
>>a single RTP session. So, wouldn’t the three SSRCs be reported in 
>Each of the SSRCs will report on all the others, unless the 
>rtp-multi-stream-optimisation draft is used, but so what?

Oh, I think I understand what you are saying.  You're saying that each 
media flow (SSRC) would be responsible for sending its own RTCP packets 
and those packets would be marked in the same way as that media flow.  
In that case, I agree with you.

That said, would we really require the sending SSRC to include any data 
for the other SSRCs if they're each sending RTCP packets separately?  
That seems redundant.  Does RFC 3550 require that?  (It's been a 
while...)

>>>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?
>>
>You mean the RTCP for each SSRC should use the DSCP with the lowest 
>drop preference of those used for the media sent by that SSRC?

That's what I'm suggesting. So, a video flow using AF4x would use AF41 
for RTCP.  I suggest that, since I assume we don't want to lose feedback 
information if we can avoid it.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 27 Aug 2014 22:52:49 +0000

RTCP might not be used for RTT calculations (it might; I just doubt it's 
terribly useful),  but RTCP might be used to convey QoE measurements or 
one-way delay information useful for RMCAT.

I think there is agreement that the DSCP value applied to the RTCP 
packet for a given SSRC sender should align with the DSCP value used for 
the corresponding RTP packets of that sender. In the case where an AFxx 
class is used, I'm not sure there is agreement (though no disagreement). 
  I stated my view that we should use the lowest drop precedence in that 
case, but others should weigh in.

Paul

------ Original Message ------
From: "Ben Campbell" <[email-masked]>
To: "Michael Welzl" <[email-masked]>; "Colin Perkins" 
<[email-masked]>; "Paul E. Jones" <[email-masked]>; "Black, 
David" <[email-masked]>
Cc: "[email-masked]" 
<[email-masked]>; "[email-masked]" 
<[email-masked]>; "[email-masked] WG" <[email-masked]>
Sent: 8/27/2014 4:48:37 PM
Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin Perkins 
comments - WGLC: draft-ietf-dart-dscp-rtp-02)

>>  for the short dialogue between Colin and me, the conclusion is: Colin 
>>is right. RTCP probably won't be used by congestion control to 
>>estimate the RTT.
>>
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 28 Aug 2014 12:05:43 +0100

Paul,

On 27 Aug 2014, at 22:41, Paul E. Jones <[email-masked]> wrote:
> Oh, I think I understand what you are saying.  You're saying that each media flow (SSRC) would be responsible for sending its own RTCP packets and those packets would be marked in the same way as that media flow.  In that case, I agree with you.

Yes.

> That said, would we really require the sending SSRC to include any data for the other SSRCs if they're each sending RTCP packets separately?  That seems redundant.  Does RFC 3550 require that?  (It’s been a while...)

RFC 3550 does require that, and it is redundant (except that it indicates that the SSRCs are co-located); draft-ietf-avtcore-rtp-multi-stream-optimisation-04 offers an extension to avoid it in some cases.

> That's what I'm suggesting. So, a video flow using AF4x would use AF41 for RTCP.  I suggest that, since I assume we don't want to lose feedback information if we can avoid it.

Makes sense.

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

---

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

> I'd agree if I didn't have the impression, in RMCAT, that nothing but RTP / RTCP is allowed?!  So can we send extra packets to probe for the RTT?

Yes, as I replied a couple of days ago. 

Colin

---

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

> Yes, as I replied a couple of days ago. 

Wait, sorry, that was the email I replied to a couple of days ago reappearing… RTT probing, I guess :-)

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