Re: [AVTCORE] Treatment of RTCP - proposed text

"Black, David" <david.black@emc.com> Thu, 28 August 2014 04:48 UTC

Return-Path: <david.black@emc.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458CE1A034A; Wed, 27 Aug 2014 21:48:09 -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 bHlYO_wFdWYA; Wed, 27 Aug 2014 21:48:07 -0700 (PDT)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3751A0349; Wed, 27 Aug 2014 21:48:06 -0700 (PDT)
Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7S4lxLR017660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2014 00:47:59 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s7S4lxLR017660
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409201280; bh=9DxnFtbxcIa8wJFe5GPj6gmXfww=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=p8uzUj8SBvVRJAk0O2USKpXyUnHv6ku9MyGPr0UEBMEGN90QRZ6rmvaYtZJc7R+45 IvxsQKjobbFtMdLZ0qNI0Hz8ScjPz7C5f5vCdvTIOMbuLGUpnasRMneNMaBonRDvOX WIrOWZMt7Lndd2K86C5bUhq1aMLKAQsFkK3a/kPI=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s7S4lxLR017660
Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd06.lss.emc.com (RSA Interceptor); Thu, 28 Aug 2014 00:47:30 -0400
Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7S4lfLM028512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 00:47:41 -0400
Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Thu, 28 Aug 2014 00:47:41 -0400
From: "Black, David" <david.black@emc.com>
To: "Paul E. Jones" <paulej@packetizer.com>, Ben Campbell <ben@nostrum.com>, Michael Welzl <michawe@ifi.uio.no>, Colin Perkins <csp@csperkins.org>
Date: Thu, 28 Aug 2014 00:47:37 -0400
Thread-Topic: Treatment of RTCP - proposed text
Thread-Index: Ac/CbhI+AlHlfm/rTqu1eBFqk0J/QgACzZew
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BC6669E@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE712077BB4310B@MX15A.corp.emc.com> <emc6d51676-add4-404b-bd0a-d6dbf3833abb@sydney>
In-Reply-To: <emc6d51676-add4-404b-bd0a-d6dbf3833abb@sydney>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com
X-RSA-Classifications: public
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/tljgMCE-AVs3IXuT9jUo7vP_dsc
Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" <draft-ietf-dart-dscp-rtp.all@tools.ietf.org>, "Black, David" <david.black@emc.com>, "dart@ietf.org" <dart@ietf.org>, "avt@ietf.org WG" <avt@ietf.org>
Subject: Re: [AVTCORE] Treatment of RTCP - proposed text
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 04:48:09 -0000

> Should it be the DSCP value of the SSRC being reported on or the DSCP of
> the SSRC sender?  

It should be the SSRC/RTP stream DSCP.  I think the proposed text covers
that for both the SR and RR cases (Bob would use EF in your example), but
I admit to thinking more about RRs when I wrote the proposed text.

If there are 31 flows being reported on in a single RTCP RR, I think
the receiver just picks a DSCP, as it may not know the DSCPs for any
of the flows (e.g., if they've all been remarked enroute).  I do like
the idea of having the reporter use the DSCP that it would use to send
a similar RTP stream - I'd be happy to slim the text down to only 
recommend that, as it's simpler and the RTCP sender should always know
what DSCP it would use if it were sending similar media.

Thanks,
--David

> -----Original Message-----
> From: Paul E. Jones [mailto:paulej@packetizer.com]
> Sent: Wednesday, August 27, 2014 11:14 PM
> To: Black, David; Ben Campbell; Michael Welzl; Colin Perkins
> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org; dart@ietf.org; avt@ietf.org
> WG; Black, David
> Subject: Re: Treatment of RTCP - proposed text
> 
> David,
> 
> Should it be the DSCP value of the SSRC being reported on or the DSCP of
> the SSRC sender?  My thought that was if Alice and Bob are sending flows
> to each other and Bob is sending audio using EF, then when Bob sends out
> a Sender Report, the packet would be marked EF.  The way this is worded,
> if Alice is sending packets using CS0, then Bob would mark his SR's
> using CS0.
> 
> I'm not sure how to handle the RR's, though, particularly of a
> receive-only device.  We could say it would be the same as the flow
> being reported on, but there might be 31 such flows being reported on.
> Perhaps if there is agreement that the RTCP packets will be marked in
> the same way as the sender would send its media, then we say the reports
> should be marked in the same was as it would if it did send media.
> 
> So, do we want RTCP packets to be marked the same as the media flow
> transmitted or the same as the received media flow?
> 
> Paul
> 
> ------ Original Message ------
> From: "Black, David" <david.black@emc.com>
> To: "Paul E. Jones" <paulej@packetizer.com>; "Ben Campbell"
> <ben@nostrum.com>; "Michael Welzl" <michawe@ifi.uio.no>; "Colin Perkins"
> <csp@csperkins.org>
> Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org"
> <draft-ietf-dart-dscp-rtp.all@tools.ietf.org>; "dart@ietf.org"
> <dart@ietf.org>; "avt@ietf.org WG" <avt@ietf.org>; "Black, David"
> <david.black@emc.com>
> Sent: 8/27/2014 9:58:34 PM
> Subject: Treatment of RTCP - proposed text
> 
> >Trying to propose some text here:
> >
> >OLD
> >    o Should use a single DSCP for an RTCP session, primarily to avoid
> >       RTCP reordering (and because there is no compelling reason for use
> >       of different drop precedences). One of the PHBs and associated
> >       DSCP used for the associated RTP traffic would be an appropriate
> >       choice. [Editor's note: This bullet is an open technical issue.]
> >NEW
> >    o Should use the same DSCP for RTCP reports as used for the RTP stream
> >       that is being reported on when that DSCP is known by the RTCP sender.
> >       When an RTP stream uses multiple DSCPs that differ only in drop
> >       precedence, RTCP reports on that RTP stream should use the DSCP with
> >       the least likelihood of drop to favor delivery of the RTCP reports.
> >       When a single RTCP message reports on multiple RTP streams that
> >       are sent with different DSCPs, the RTCP sender should choose one
> >       of those DSCPs. When the RTCP sender does not know what DSCP or
> >       DSCPs were used to send an RTP stream, it should choose a DSCP
> >       that it would use to send a similar RTP stream.
> >
> >The latter sentence is courtesy of the fact that there will be cases
> >where the RTCP sender will not know what DSCP or DSCPs were used to
> >send the RTP stream, due to en-route remarking.
> >
> >If that text looks close, I'll edit further and try to get the -05
> >submitted by the end of this week.
> >
> >Thanks,
> >--David
> >
> >>  -----Original Message-----
> >>  From: Paul E. Jones [mailto:paulej@packetizer.com]
> >>  Sent: Wednesday, August 27, 2014 6:53 PM
> >>  To: Ben Campbell; Michael Welzl; Colin Perkins; Black, David
> >>  Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org; dart@ietf.org;
> >>avt@ietf.org
> >>  WG
> >>  Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin
> >>Perkins
> >>  comments - WGLC: draft-ietf-dart-dscp-rtp-02)
> >>
> >>  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" <ben@nostrum.com>
> >>  To: "Michael Welzl" <michawe@ifi.uio.no>; "Colin Perkins"
> >>  <csp@csperkins.org>; "Paul E. Jones" <paulej@packetizer.com>; "Black,
> >>  David" <david.black@emc.com>
> >>  Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org"
> >>  <draft-ietf-dart-dscp-rtp.all@tools.ietf.org>; "dart@ietf.org"
> >>  <dart@ietf.org>; "avt@ietf.org WG" <avt@ietf.org>
> >>  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)
> >>
> >>  >On Aug 27, 2014, at 3:45 PM, Michael Welzl <michawe@ifi.uio.no>
> >>wrote:
> >>  >
> >>  >> 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.
> >>  >>
> >>  >
> >>  >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.
> >>  >
> >>  >
> >>  >_______________________________________________
> >>  >Dart mailing list
> >>  >Dart@ietf.org
> >>  >https://www.ietf.org/mailman/listinfo/dart
> >