Re: [AVTCORE] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02

[Colin Perkins <[e-mail]>]

Hi,

On 22 Aug 2014, at 21:12, Black, David <[e-mail]> wrote:
> 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.

That’s fine.

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

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/