Re: [Dart] DART dscp-rtp draft: Proposed RTCP text

"Black, David" <david.black@emc.com> Fri, 29 August 2014 15:17 UTC

Return-Path: <david.black@emc.com>
X-Original-To: dart@ietfa.amsl.com
Delivered-To: dart@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D5B1A04B4; Fri, 29 Aug 2014 08:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.969
X-Spam-Level:
X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpUncfbJGWv6; Fri, 29 Aug 2014 08:17:48 -0700 (PDT)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE611A0458; Fri, 29 Aug 2014 08:17:47 -0700 (PDT)
Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7TFHeiF005836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2014 11:17:40 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7TFHeiF005836
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409325461; bh=HryKPkqFz/Va5R08qcJj/XoiYyI=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=OYCQqpxtdClwfZPgIIKnawpCbnMEDFEglaEJFh6iMQefa00UPfbukl+yYWzlzEU+l 1E3B8dREH9I6czc+6dQlNtmthdyEE1UBqZjIHIbeJQ1azVj8HshatLnRMLOg6hfP/s stDtqW3VFBhz8sJmPVUQaongKcQo1BNUShC91OoQ=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7TFHeiF005836
Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd56.lss.emc.com (RSA Interceptor); Fri, 29 Aug 2014 11:17:20 -0400
Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7TFHLOt009791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Aug 2014 11:17:21 -0400
Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Fri, 29 Aug 2014 11:17:21 -0400
From: "Black, David" <david.black@emc.com>
To: Colin Perkins <csp@csperkins.org>
Date: Fri, 29 Aug 2014 11:17:19 -0400
Thread-Topic: [Dart] DART dscp-rtp draft: Proposed RTCP text
Thread-Index: Ac/DAwWQxpe1fBhmTFScFqzEgvjSRwAmPTfw
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BC66920@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE712077BC6682D@MX15A.corp.emc.com> <4DF64F47-D5DF-4202-9E7E-9CF570C840B3@csperkins.org>
In-Reply-To: <4DF64F47-D5DF-4202-9E7E-9CF570C840B3@csperkins.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com
X-RSA-Classifications: public
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/GcBuovGAhGrbFHp3Ejy5nbE3VQY
Cc: "ben@nostrum.com" <ben@nostrum.com>, "dart@ietf.org" <dart@ietf.org>, "avt@ietf.org WG \(avt@ietf.org\)" <avt@ietf.org>
Subject: Re: [Dart] DART dscp-rtp draft: Proposed RTCP text
X-BeenThere: dart@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <dart.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dart>, <mailto:dart-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dart/>
List-Post: <mailto:dart@ietf.org>
List-Help: <mailto:dart-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dart>, <mailto:dart-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Aug 2014 15:17:50 -0000

Colin,

Many thanks, once again!

I'm about to submit a -05 version of the DART draft that reflects
this feedback, and also says that we're using SSRC as both the
identifier of an RTP stream and to designate the sender of that
RTP stream  (the new terminology draft uses Media Packetizer
as the term for the sender of an RTP stream).

Thanks,
--David


> -----Original Message-----
> From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Colin Perkins
> Sent: Thursday, August 28, 2014 4:59 PM
> To: Black, David
> Cc: ben@nostrum.com; dart@ietf.org; avt@ietf.org WG (avt@ietf.org)
> Subject: Re: [Dart] DART dscp-rtp draft: Proposed RTCP text
> 
> On 28 Aug 2014, at 20:45, Black, David <david.black@emc.com>; wrote:
> > Here's the proposed new section 5.4, with the RTCP multi-stream reporting
> > optimizations text moved into that new section from its current location
> > at the end of 5.3, plus the rewritten Section 6 guideline bullet:
> >
> > 5.4.  DiffServ and RTCP
> >
> >   The RTP Control Protocol (RTCP) [RFC3550] is used with RTP to monitor
> >   quality of service and convey information about RTP session
> >   participants.  A sender of RTCP packets that also sends RTP packets
> >   (i.e., originates an RTP stream) should use the same DSCP marking for
> >   both types of packets.  If an RTCP sender doesn't send any RTP
> >   packets, it should mark its RTCP packets with the DSCP that it would
> >   use if it did send RTP packets.  If the RTCP sender uses or would use
> >   multiple DSCPs that differ only in drop precedence for RTP, then it
> >   should use the DSCP with the least likelihood of drop for RTCP to
> >   increase the likelihood of RTCP packet delivery.
> 
> This looks okay (the correction in your next message is good also).
> 
> You might also add something along the lines of "If the SDP bundle extension
> [cite] is used to negotiate sending multiple types of media in a single RTP
> session, then the receivers will send separate RTCP reports for each type of
> media, using a separate SSRC for each media type; those RTCP reports need to
> be marked with the DSCP corresponding to the type of media handled by the
> reporting SSRC."
> 
> >   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.
> 
> I don't think this is a problem. The media doesn't get consistent network QoS
> treatment in both directions, and the RTCP is trying to sample the RTT seen by
> the media, so this is fine.
> 
> >   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.
> >
> >   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 network behavior, including
> >   packet loss.  This mechanism is highly inappropriate when the RTP
> >   streams involved use different DSCPs, even if the corresponding PHBs
> >   differ solely in drop precedence.
> 
> This could maybe say "received RTP streams", since it's okay to use the rtp-
> multi-stream-optimisation if you send with different DSCPs (the optimisation
> is optimising how you send reports about what you receive).
> 
> > 6.  Guidelines
> >
> > [... snip ...]
> >
> >   o  Should use a single DSCP for RTCP packets, which should be a DSCP
> >      used for RTP packets that are or would be sent by the same sender,
> >      see Section 5.4.
> 
> Perhaps "Each SSRC should use a single DSCP for RTCP ... used by RTP packets
> that are or would be sent by that SSRC..."? Just "sender" could be ambiguous,
> since an endpoint could be a sender for several streams, each of which has a
> separate SSRC and could use a different DSCP.
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> Dart mailing list
> Dart@ietf.org
> https://www.ietf.org/mailman/listinfo/dart