From nobody Tue Aug 5 12:40:59 2014 Return-Path: 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 9DCDD1A0149 for ; Tue, 5 Aug 2014 12:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 o3NfOK5ugywB for ; Tue, 5 Aug 2014 12:40:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1641A014A for ; Tue, 5 Aug 2014 12:40:54 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s75JeiiK095035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Aug 2014 14:40:48 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077860E55C@MX15A.corp.emc.com> Date: Tue, 5 Aug 2014 14:40:44 -0500 X-Mao-Original-Outgoing-Id: 428960444.403094-1177972c2c9b2980777a01adeddaf89d Content-Transfer-Encoding: quoted-printable Message-Id: <5024D1F3-242E-43BF-9572-4C72669EFBB6@nostrum.com> References: <20140731190738.16865.76561.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712077860E55C@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Ih-gDHdtgekJJ5k_M8NPqh60H50 Cc: "dart@ietf.org" Subject: Re: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 19:40:57 -0000 (as individual) -- General I concur with the editor's note to reorganize sections. On my first = reading, I was going to comment that I thought we needed more focus on = what is really likely to happen, e.g. with WebRTC. On a second reading, = I think that's mostly okay, but the consolidation of the RTP sections = might make it more clear. -- Section 4, Bullets 3 and 4: Should STP in bullet 4 be SCTP? If yes, then doesn't this bullet more = tightly constrain things than bullet 3, to the point of making bullet 3 = redundant? Or am I misreading something? Thanks! Ben. On Jul 31, 2014, at 3:50 PM, Black, David wrote: > As promised, here's the -00 dart WG draft. I think I incorporated = almost > everything that was discussed in the meeting, but I've surely missed a > few things - please comment (on list, or send me editorial changes = directly). >=20 > I want to call attention to this Editor's Note on draft organization: >=20 > [Editor's Note: Current section structure skips around topics > somewhat. The editor suggests restructuring to put real-time/RTP > material first (new section 2, consisting of current sections 2, 2.1 > and 3), then DiffServ Background (new section 3, consisting of > current sections 2.2, 2.3, 2.6 and 2.7, followed by discussion of > interactions (new section 4, consisting of current sections 2.4, 2.5 > and 5) and guidelines (current section 4, renumbered to new section > 5).] >=20 > If this change is made, I will submit a version that only contains the > text rearrangement before making any other changes. The "game plan" = that > I've discussed w/Ben (WG chair) is to revise the draft over about the = next > week with the resulting version going to WG Last Call, so reading this > draft sooner rather than later might be a good idea. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf = Of >> internet-drafts@ietf.org >> Sent: Thursday, July 31, 2014 3:08 PM >> To: i-d-announce@ietf.org >> Cc: dart@ietf.org >> Subject: I-D Action: draft-ietf-dart-dscp-rtp-00.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the DiffServ Applied to Real-time = Transports >> Working Group of the IETF. >>=20 >> Title : Differentiated Services (DiffServ) and = Real-time >> Communication >> Authors : David Black >> Paul Jones >> Filename : draft-ietf-dart-dscp-rtp-00.txt >> Pages : 23 >> Date : 2014-07-31 >>=20 >> Abstract: >> This document describes the interaction between Differentiated >> Services (DiffServ) network quality of service (QoS) functionality >> and real-time network communication, including communication based = on >> the Real-time Transport Protocol (RTP). DiffServ is based on = network >> nodes applying different forwarding treatments to packets whose IP >> headers are marked with different DiffServ Code Points (DSCPs). As = a >> result, use of different DSCPs within a single traffic stream may >> cause transport protocol interactions (e.g., reordering). In >> addition, DSCP markings may be changed or removed between the = traffic >> source and destination. This document covers the implications of >> these DiffServ aspects for real-time network communication, = including >> RTCWEB. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Tue Aug 5 16:34:55 2014 Return-Path: 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 772251A0339 for ; Tue, 5 Aug 2014 16:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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.001, 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 QdIEOQuhPzS8 for ; Tue, 5 Aug 2014 16:34:52 -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 7A6251A032F for ; Tue, 5 Aug 2014 16:34:52 -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 s75NYnJ8029607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Aug 2014 19:34:51 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s75NYnJ8029607 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1407281691; bh=sG/qgH1MBbIfPJiNSMFVR/x+6hU=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ghA7oITXbWSEfwhSnQmXTceFbNSequxGuSbZBP+FQA9PbjLvL4k64rNbCso5UyuCZ C2mWti1HSLMOahW1SuEalIP0LYTmyPobWwoRS/Teg6zBLTKkL5t1PZO+HuLOwuToqE cvyWtoZz7B7vwC9/1IWvSouVpd7G5AsLp5s7meHo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s75NYnJ8029607 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd56.lss.emc.com (RSA Interceptor); Tue, 5 Aug 2014 19:34:29 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s75NYSMN009887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 19:34:29 -0400 Received: from mx15a.corp.emc.com ([169.254.1.206]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Tue, 5 Aug 2014 19:34:28 -0400 From: "Black, David" To: Ben Campbell Date: Tue, 5 Aug 2014 19:34:27 -0400 Thread-Topic: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-00.txt Thread-Index: Ac+w5S4n0lQKOOhlSK6V6k4pU95ylQAIALZQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120779DE6F05@MX15A.corp.emc.com> References: <20140731190738.16865.76561.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712077860E55C@MX15A.corp.emc.com> <5024D1F3-242E-43BF-9572-4C72669EFBB6@nostrum.com> In-Reply-To: <5024D1F3-242E-43BF-9572-4C72669EFBB6@nostrum.com> 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: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/9AV-jBY16DH1ckInmhRLn3gu9_o Cc: "Black, David" , "dart@ietf.org" Subject: Re: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-00.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 23:34:54 -0000 Ben, Thank you for reviewing this draft. > I concur with the editor's note to reorganize sections. Thank you - anyone else care to weigh in? > -- Section 4, Bullets 3 and 4: >=20 > Should STP in bullet 4 be SCTP? Yes, I'd plead gasoline fumes ;-), but I actually missed this in rapid-fire editing to try to pick up everything from the productive Toronto dart meeti= ng. > If yes, then doesn't this bullet more tightly > constrain things than bullet 3, to the point of making bullet 3 redundant= ? Or > am I misreading something? I think that's correct - bullets 3 and 4 should be combined. Thanks, --David > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, August 05, 2014 3:41 PM > To: Black, David > Cc: dart@ietf.org > Subject: Re: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-00.txt >=20 > (as individual) >=20 > -- General >=20 > I concur with the editor's note to reorganize sections. On my first readi= ng, I > was going to comment that I thought we needed more focus on what is reall= y > likely to happen, e.g. with WebRTC. On a second reading, I think that's m= ostly > okay, but the consolidation of the RTP sections might make it more clear. >=20 > -- Section 4, Bullets 3 and 4: >=20 > Should STP in bullet 4 be SCTP? If yes, then doesn't this bullet more tig= htly > constrain things than bullet 3, to the point of making bullet 3 redundant= ? Or > am I misreading something? >=20 > Thanks! >=20 > Ben. >=20 > On Jul 31, 2014, at 3:50 PM, Black, David wrote: >=20 > > As promised, here's the -00 dart WG draft. I think I incorporated almo= st > > everything that was discussed in the meeting, but I've surely missed a > > few things - please comment (on list, or send me editorial changes > directly). > > > > I want to call attention to this Editor's Note on draft organization: > > > > [Editor's Note: Current section structure skips around topics > > somewhat. The editor suggests restructuring to put real-time/RTP > > material first (new section 2, consisting of current sections 2, 2.1 > > and 3), then DiffServ Background (new section 3, consisting of > > current sections 2.2, 2.3, 2.6 and 2.7, followed by discussion of > > interactions (new section 4, consisting of current sections 2.4, 2.5 > > and 5) and guidelines (current section 4, renumbered to new section > > 5).] > > > > If this change is made, I will submit a version that only contains the > > text rearrangement before making any other changes. The "game plan" th= at > > I've discussed w/Ben (WG chair) is to revise the draft over about the n= ext > > week with the resulting version going to WG Last Call, so reading this > > draft sooner rather than later might be a good idea. > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > >> internet-drafts@ietf.org > >> Sent: Thursday, July 31, 2014 3:08 PM > >> To: i-d-announce@ietf.org > >> Cc: dart@ietf.org > >> Subject: I-D Action: draft-ietf-dart-dscp-rtp-00.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the DiffServ Applied to Real-time Transpo= rts > >> Working Group of the IETF. > >> > >> Title : Differentiated Services (DiffServ) and Real-t= ime > >> Communication > >> Authors : David Black > >> Paul Jones > >> Filename : draft-ietf-dart-dscp-rtp-00.txt > >> Pages : 23 > >> Date : 2014-07-31 > >> > >> Abstract: > >> This document describes the interaction between Differentiated > >> Services (DiffServ) network quality of service (QoS) functionality > >> and real-time network communication, including communication based o= n > >> the Real-time Transport Protocol (RTP). DiffServ is based on networ= k > >> nodes applying different forwarding treatments to packets whose IP > >> headers are marked with different DiffServ Code Points (DSCPs). As = a > >> result, use of different DSCPs within a single traffic stream may > >> cause transport protocol interactions (e.g., reordering). In > >> addition, DSCP markings may be changed or removed between the traffi= c > >> source and destination. This document covers the implications of > >> these DiffServ aspects for real-time network communication, includin= g > >> RTCWEB. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-00 > >> > >> > >> Please note that it may take a couple of minutes from the time of > submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > Dart mailing list > > Dart@ietf.org > > https://www.ietf.org/mailman/listinfo/dart From nobody Fri Aug 8 16:03:51 2014 Return-Path: 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 3E4D21A016D; Fri, 8 Aug 2014 16:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ENGQXKjxnkqN; Fri, 8 Aug 2014 16:03:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEC51A0151; Fri, 8 Aug 2014 16:03:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808230343.6847.40060.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 16:03:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/m7_2pFWvt3ou2HiNNBFlQ9ENaNQ Cc: dart@ietf.org Subject: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-01.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 23:03:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DiffServ Applied to Real-time Transports Working Group of the IETF. Title : Differentiated Services (DiffServ) and Real-time Communication Authors : David Black Paul Jones Filename : draft-ietf-dart-dscp-rtp-01.txt Pages : 24 Date : 2014-08-08 Abstract: This document describes the interaction between Differentiated Services (DiffServ) network quality of service (QoS) functionality and real-time network communication, including communication based on the Real-time Transport Protocol (RTP). DiffServ is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different DiffServ Code Points (DSCPs). As a result, use of different DSCPs within a single traffic stream may cause transport protocol interactions (e.g., reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This document covers the implications of these DiffServ aspects for real-time network communication, including RTCWEB. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dart-dscp-rtp-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 8 16:52:55 2014 Return-Path: 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 E5CEC1A023E for ; Fri, 8 Aug 2014 16:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 0ar4By1y3uoe for ; Fri, 8 Aug 2014 16:52:50 -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 ED1D11A01EB for ; Fri, 8 Aug 2014 16:52:49 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s78NqmGK024040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Aug 2014 19:52:48 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s78NqmGK024040 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1407541968; bh=pakFimFM6xzleRVAjtBx4qzgSt4=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=oPXuHl7/NrZljUPWmJ6MTnMz70xYvdqe91vkAlzjthnxhtZJjN4mbQrMy0xFEB1pa UWMpCs/5/RM7GeUwrwugEItnuxdHic413ZBSVRDvusQbd9OZDYG6/73+fJ6jYQY2fm UvE7wazjNcfmYNpqKnljGby1/TvCrlQ6Ww3MG+0k= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s78NqmGK024040 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd02.lss.emc.com (RSA Interceptor) for ; Fri, 8 Aug 2014 19:52:30 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s78NqTEb012816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Aug 2014 19:52:30 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Fri, 8 Aug 2014 19:52:29 -0400 From: "Black, David" To: "dart@ietf.org" Date: Fri, 8 Aug 2014 19:52:27 -0400 Thread-Topic: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-01.txt Thread-Index: Ac+zXQlMwOddhb0MTQaCS0i14Jp7KQAACsMQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077B9518E2@MX15A.corp.emc.com> References: <20140808230343.6847.40060.idtracker@ietfa.amsl.com> In-Reply-To: <20140808230343.6847.40060.idtracker@ietfa.amsl.com> 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: mailusrhubprd04.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/8u6caGf99IRgbMQsayjfor3_0a8 Subject: Re: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-01.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 23:52:53 -0000 This -01 version has the editorial and content changes, primarily from a review by Gorry Fairhurst (who also supplied material on DCCP and UDP-Lit= e). The next -02 version will rearrange the section order and numbering along w= ith any edits that are needed as a result - that should be ready for WG Last Ca= ll. Thanks, --David > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, August 08, 2014 7:04 PM > To: i-d-announce@ietf.org > Cc: dart@ietf.org > Subject: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DiffServ Applied to Real-time Transport= s > Working Group of the IETF. >=20 > Title : Differentiated Services (DiffServ) and Real-tim= e > Communication > Authors : David Black > Paul Jones > Filename : draft-ietf-dart-dscp-rtp-01.txt > Pages : 24 > Date : 2014-08-08 >=20 > Abstract: > This document describes the interaction between Differentiated > Services (DiffServ) network quality of service (QoS) functionality > and real-time network communication, including communication based on > the Real-time Transport Protocol (RTP). DiffServ is based on network > nodes applying different forwarding treatments to packets whose IP > headers are marked with different DiffServ Code Points (DSCPs). As a > result, use of different DSCPs within a single traffic stream may > cause transport protocol interactions (e.g., reordering). In > addition, DSCP markings may be changed or removed between the traffic > source and destination. This document covers the implications of > these DiffServ aspects for real-time network communication, including > RTCWEB. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dart-dscp-rtp-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Fri Aug 8 17:08:11 2014 Return-Path: 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 82CD71A024F; Fri, 8 Aug 2014 17:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Ks0S0IEs_LNT; Fri, 8 Aug 2014 17:08:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D8D1A023E; Fri, 8 Aug 2014 17:08:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140809000807.29086.34911.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 17:08:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/koQ2Yc9m8bF2tYP2tJy4E1llHtc Cc: dart@ietf.org Subject: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-02.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 00:08:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DiffServ Applied to Real-time Transports Working Group of the IETF. Title : Differentiated Services (DiffServ) and Real-time Communication Authors : David Black Paul Jones Filename : draft-ietf-dart-dscp-rtp-02.txt Pages : 25 Date : 2014-08-08 Abstract: This document describes the interaction between Differentiated Services (DiffServ) network quality of service (QoS) functionality and real-time network communication, including communication based on the Real-time Transport Protocol (RTP). DiffServ is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different DiffServ Code Points (DSCPs). As a result, use of different DSCPs within a single traffic stream may cause transport protocol interactions (e.g., reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This document covers the implications of these DiffServ aspects for real-time network communication, including RTCWEB. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dart-dscp-rtp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 8 17:09:38 2014 Return-Path: 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 B5B261A024F for ; Fri, 8 Aug 2014 17:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 iNwijWp7WwPZ for ; Fri, 8 Aug 2014 17:09:33 -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 914931A023E for ; Fri, 8 Aug 2014 17:09:33 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7909Wah028129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Aug 2014 20:09:32 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7909Wah028129 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1407542972; bh=7naomfyzLaXSdohUdddKFFNtX10=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=cos2FITzxJgKBG/MZlwbzWw3MH+DAQNE9rhbRazbsUrlhaAAKRNKF0tr5IvQUnQdh p8JCJ12bM9MkRdUSir1EJV2AGczw1H3x44Ovj1L0QhDLfWkZj08sUOJExJ4Ie50hvv +CbCVXFQHnXXEMGlYOnqB85SmOz95fYFR/JkuF9s= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7909Wah028129 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd03.lss.emc.com (RSA Interceptor) for ; Fri, 8 Aug 2014 20:09:14 -0400 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7909E3W008674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Aug 2014 20:09:14 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Fri, 8 Aug 2014 20:09:13 -0400 From: "Black, David" To: "dart@ietf.org" Date: Fri, 8 Aug 2014 20:09:13 -0400 Thread-Topic: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-02.txt Thread-Index: Ac+zZga8cO1lYD6GRdCUVumSPaNweAAAAY9w Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077B9518E3@MX15A.corp.emc.com> References: <20140809000807.29086.34911.idtracker@ietfa.amsl.com> In-Reply-To: <20140809000807.29086.34911.idtracker@ietfa.amsl.com> 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: mailusrhubprd51.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/qMSv0GGUv04QIWAyjvrIj6cw2ow Subject: Re: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-02.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 00:09:35 -0000 And this one rearranges the text (plus makes some minor associated edits). It should be ready for WG Last Call. Thanks, --David > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, August 08, 2014 8:08 PM > To: i-d-announce@ietf.org > Cc: dart@ietf.org > Subject: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DiffServ Applied to Real-time Transport= s > Working Group of the IETF. >=20 > Title : Differentiated Services (DiffServ) and Real-tim= e > Communication > Authors : David Black > Paul Jones > Filename : draft-ietf-dart-dscp-rtp-02.txt > Pages : 25 > Date : 2014-08-08 >=20 > Abstract: > This document describes the interaction between Differentiated > Services (DiffServ) network quality of service (QoS) functionality > and real-time network communication, including communication based on > the Real-time Transport Protocol (RTP). DiffServ is based on network > nodes applying different forwarding treatments to packets whose IP > headers are marked with different DiffServ Code Points (DSCPs). As a > result, use of different DSCPs within a single traffic stream may > cause transport protocol interactions (e.g., reordering). In > addition, DSCP markings may be changed or removed between the traffic > source and destination. This document covers the implications of > these DiffServ aspects for real-time network communication, including > RTCWEB. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dart-dscp-rtp-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Sat Aug 9 10:50:29 2014 Return-Path: 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 554481A00EF for ; Sat, 9 Aug 2014 10:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.668] 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 3Yk4MJkuXHf4 for ; Sat, 9 Aug 2014 10:50:23 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E131A0092 for ; Sat, 9 Aug 2014 10:50:23 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s79HoHHO010624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 9 Aug 2014 12:50:19 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell Date: Sat, 9 Aug 2014 12:50:16 -0500 X-Mao-Original-Outgoing-Id: 429299416.927195-a3e61c3fe34736d78880e38f15195c72 Content-Transfer-Encoding: quoted-printable Message-Id: To: dart@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/C4f68HJEvWNYNKrH7xsKOQOGlrM Cc: Richard Barnes , draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com Subject: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 17:50:25 -0000 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. From nobody Mon Aug 11 03:22:01 2014 Return-Path: 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 B6E091A03FF; Mon, 11 Aug 2014 03:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.118 X-Spam-Level: X-Spam-Status: No, score=-3.118 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 NAHagK2RxI3P; Mon, 11 Aug 2014 03:21:47 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D7031A03F7; Mon, 11 Aug 2014 03:21:46 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail41.telekom.de with ESMTP; 11 Aug 2014 12:21:39 +0200 X-IronPort-AV: E=Sophos;i="5.01,840,1400018400"; d="scan'208";a="118455659" Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 11 Aug 2014 12:21:14 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 11 Aug 2014 12:21:13 +0200 From: To: Date: Mon, 11 Aug 2014 12:21:12 +0200 Thread-Topic: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 Thread-Index: Ac+z+nRLTxiz6TcWSyWF7k9hB70xAwBPUAHQ Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/UsYfz6Z4wESnQi_HTIadgAH4UyQ Cc: dart@ietf.org, tsvwg@ietf.org Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 10:21:51 -0000 Hi David, new EF related text has been added in the -01 version. I've copied=20 in some text of RFC3246 related to EF remarking and policing below.=20 My take: . remarking of entire flows is an option, but no remarking of=20 packets exceeding EF capacity limits. - looking at the EF jitter and delay properties, I doubt that=20 shaping is desirable. RFC3246 doesn't mention shaping as part=20 of EF conditioning. I personally wouldn't expect EF shaping=20 in sections where policing is applied.=20 - dropping of packets exceeding EF capacity is a MUST, if I=20 interpret RFC3246 correctly. I suggest to adapt the section of draft-dart-dscp to be more=20 precise regarding the optional remarking of EF traffic and to=20 remove shaping as a conditioning option if traffic is beyond=20 the EF forwarding capacity limit. A Proposal for the final=20 sentence: ...exceeds that capacity must be dropped. EF compliant flows may=20 be remarked to a different DSCP. All other new text indicated by the Diff version looks allright. Regards, Ruediger draft-dart-dscp: 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic=09 traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865]=09 is an admission controlled variant of the EF PHB. Both of these=09 PHBs are based on pre-configured limited forwarding capacity;=09 traffic that exceeds that capacity may be shaped, remarked to a=09 different DSCP, or dropped. ######################################## RFC3246 (three excerpts): Packets belonging to a single microflow within the EF aggregate passing through a device SHOULD NOT experience re-ordering in normal operation of the device. Packets marked for EF PHB MAY be remarked at a DS domain boundary only to other codepoints that satisfy the EF PHB. Packets marked for EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS domain. If the EF PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter). Traffic that exceeds this limit MUST be discarded. -----Urspr=FCngliche Nachricht----- Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Ben Campbell Gesendet: Samstag, 9. August 2014 19:50 An: dart@ietf.org Cc: Richard Barnes; draft-ietf-dart-dscp-rtp.all@tools.ietf.org; mls.ietf@g= mail.com Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 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 go= od to go, please say so. Thanks! Ben. _______________________________________________ Dart mailing list Dart@ietf.org https://www.ietf.org/mailman/listinfo/dart From nobody Mon Aug 11 06:16:12 2014 Return-Path: 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 37B081A06FA; Mon, 11 Aug 2014 06:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 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_LOW=-0.7, 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 vWy2IqjMVU_I; Mon, 11 Aug 2014 06:16:04 -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 637871A0172; Mon, 11 Aug 2014 06:16:03 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7BDFxum030574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2014 09:16:02 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7BDFxum030574 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1407762962; bh=Yk6q0gx7Cycl8Hrs5K2zu3TzRuQ=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Y3WtXWi/G0waln9CRnqEx9tXuyeOc4VMObFZmob9FuTZ9JmlTU4++I8BdN1y0fxTJ jTyrIFZuQUmJC4BOwsSUZ3gtRgpDepbLliFeDk/p/h60FeAppy9g2AKsvfR7mT5OqU d9OlatvwYrorvbr0VjUjbuDgFU6jzcJ99oluWYUk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7BDFxum030574 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 11 Aug 2014 09:15:40 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7BDFe41005128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Aug 2014 09:15:40 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Mon, 11 Aug 2014 09:15:39 -0400 From: "Black, David" To: "Ruediger.Geib@telekom.de" Date: Mon, 11 Aug 2014 09:15:37 -0400 Thread-Topic: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 Thread-Index: Ac+z+nRLTxiz6TcWSyWF7k9hB70xAwBPUAHQAAsWe6A= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077B9519E3@MX15A.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/nsPk2kN1N-C3wYkcBxK6_UiGp1U Cc: "Black, David" , "dart@ietf.org" , "tsvwg@ietf.org" Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 13:16:07 -0000 > I suggest to adapt the section of draft-dart-dscp to be more > precise regarding the optional remarking of EF traffic and to > remove shaping as a conditioning option if traffic is beyond > the EF forwarding capacity limit. Yes, something definitely needs to be done, as shaping excess traffic is not consistent with the EF service. In addition, RFC 3246 recommends against (SHOULD NOT) remarking EF traffic within a DS domain in one of the text excerpts that was in your email, so remarking should not be mentioned as a possibility. Further, RFC 3246 recommends that excess traffic SHOULD be dropped (section 3): To protect itself against denial of service attacks, the edge of a DS domain SHOULD strictly police all EF marked packets to a rate negotiated with the adjacent upstream domain. Packets in excess of the negotiated rate SHOULD be dropped. I'll reword the dart draft text as follows: OLD Both of these PHBs are based on pre-configured limited forwarding capacity; traffic that exceeds that capacity may be shaped, remarked to a different DSCP, or dropped. NEW Both of these PHBs are based on pre-configured limited forwarding capacity; traffic in excess of that capacity is expected to be dropped. Thanks for noticing this, --David > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Monday, August 11, 2014 6:21 AM > To: Black, David > Cc: dart@ietf.org; tsvwg@ietf.org > Subject: AW: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >=20 > Hi David, >=20 > new EF related text has been added in the -01 version. I've copied > in some text of RFC3246 related to EF remarking and policing below. > My take: >=20 > . remarking of entire flows is an option, but no remarking of > packets exceeding EF capacity limits. > - looking at the EF jitter and delay properties, I doubt that > shaping is desirable. RFC3246 doesn't mention shaping as part > of EF conditioning. I personally wouldn't expect EF shaping > in sections where policing is applied. > - dropping of packets exceeding EF capacity is a MUST, if I > interpret RFC3246 correctly. >=20 > I suggest to adapt the section of draft-dart-dscp to be more > precise regarding the optional remarking of EF traffic and to > remove shaping as a conditioning option if traffic is beyond > the EF forwarding capacity limit. A Proposal for the final > sentence: >=20 > ...exceeds that capacity must be dropped. EF compliant flows may > be remarked to a different DSCP. >=20 > All other new text indicated by the Diff version looks allright. >=20 > Regards, >=20 > Ruediger >=20 >=20 >=20 > draft-dart-dscp: >=20 > 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic > traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865] > is an admission controlled variant of the EF PHB. Both of these > PHBs are based on pre-configured limited forwarding capacity; > traffic that exceeds that capacity may be shaped, remarked to a > different DSCP, or dropped. >=20 > ######################################## >=20 > RFC3246 (three excerpts): >=20 > Packets belonging to a single microflow within the EF aggregate > passing through a device SHOULD NOT experience re-ordering in normal > operation of the device. >=20 > Packets marked for EF PHB MAY be remarked at a DS domain boundary > only to other codepoints that satisfy the EF PHB. Packets marked for > EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS > domain. >=20 > If the EF PHB is implemented by a mechanism that allows unlimited > preemption of other traffic (e.g., a priority queue), the > implementation MUST include some means to limit the damage EF traffic > could inflict on other traffic (e.g., a token bucket rate limiter). > Traffic that exceeds this limit MUST be discarded. >=20 >=20 >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Ben Campbell > Gesendet: Samstag, 9. August 2014 19:50 > An: dart@ietf.org > Cc: Richard Barnes; draft-ietf-dart-dscp-rtp.all@tools.ietf.org; > mls.ietf@gmail.com > Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >=20 > 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: >=20 > https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >=20 > The WGLC will conclude on 22 August, 2014. Please send your comments to t= he > authors and the DART mailing list. If you've reviewed it and think it's g= ood > to go, please say so. >=20 > Thanks! >=20 > Ben. >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Mon Aug 11 13:13:08 2014 Return-Path: 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 1E8CB1A0004; Mon, 11 Aug 2014 13:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no 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 mToK_Zrb7Trc; Mon, 11 Aug 2014 13:13:05 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54A91A0002; Mon, 11 Aug 2014 13:13:04 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id et14so11510119pad.23 for ; Mon, 11 Aug 2014 13:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=m1e5pZ4q/VR2MWt66JLLjGGm8LAxjhTXV3DCiYfFKuU=; b=Ur2N9LXBgn3f/kvVM+wfE02+PW328N+0sDBVBubTFcgf7kFMXlD1u43EN43wl9R1Yl AktYDmcy5NNvpoTLVL/+P4b4vPnvq/BXIj5/e6Hhqp2iQN5GzmIo5IjajPzjybprIEw9 7kYsyXZI5aHa4E17z2cIFgcUWVDzGPtfWEuk3BFBjWGw/nmZ2n6xSlewJ6E7jKTwnvMc Lrjxe/RlJYopQ1rMUkjbiWD5Vtr6K+cavMnjTEq8COBzP8Vo23ILrJ2Ai6o2YnL/J9++ U99XPgenmp8W0X4PFkZRhcRD1OAyyiHBY5+pqCGu8v0dm0EcHsmJOYcI73SuC02d0pSe ps8Q== X-Received: by 10.66.122.175 with SMTP id lt15mr27061pab.77.1407787984588; Mon, 11 Aug 2014 13:13:04 -0700 (PDT) Received: from [192.168.178.23] (110.199.69.111.dynamic.snap.net.nz. [111.69.199.110]) by mx.google.com with ESMTPSA id rv10sm8642126pbc.5.2014.08.11.13.13.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 13:13:03 -0700 (PDT) Message-ID: <53E923CE.1000803@gmail.com> Date: Tue, 12 Aug 2014 08:13:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dart/x0FKvtctrtmXtSWteEIRzIbcqF4 Cc: david.black@emc.com, dart@ietf.org, tsvwg@ietf.org Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 20:13:06 -0000 Hi Ruediger, On 11/08/2014 22:21, Ruediger.Geib@telekom.de wrote: > Hi David, >=20 > new EF related text has been added in the -01 version. I've copied=20 > in some text of RFC3246 related to EF remarking and policing below.=20 > My take: >=20 > . remarking of entire flows is an option, but no remarking of=20 > packets exceeding EF capacity limits. > - looking at the EF jitter and delay properties, I doubt that=20 > shaping is desirable. RFC3246 doesn't mention shaping as part=20 > of EF conditioning. I personally wouldn't expect EF shaping=20 > in sections where policing is applied.=20 > - dropping of packets exceeding EF capacity is a MUST, if I=20 > interpret RFC3246 correctly. Well, it seems to me to be a SHOULD, with the MUST that you cite below being conditional on "a mechanism that allows unlimited preemption of other traffic." So I would not be at all surprised by deployments that support shaping and remarking. Also, there are certainly implementations that are closer to RFC 2598 or RFC 3248 and therefore less strict. I think the draft should make it clear that there is likely to be variation in actual behaviour for EF traffic that exceeds the nominal rate. (Leaving aside the fact that without a string of matching SLAs along the path, the nominal rate might not even be well defined.) Brian >=20 > I suggest to adapt the section of draft-dart-dscp to be more=20 > precise regarding the optional remarking of EF traffic and to=20 > remove shaping as a conditioning option if traffic is beyond=20 > the EF forwarding capacity limit. A Proposal for the final=20 > sentence: >=20 > ...exceeds that capacity must be dropped. EF compliant flows may=20 > be remarked to a different DSCP. >=20 > All other new text indicated by the Diff version looks allright. >=20 > Regards, >=20 > Ruediger >=20 >=20 >=20 > draft-dart-dscp: >=20 > 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic=09 > traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865]=09 > is an admission controlled variant of the EF PHB. Both of these=09 > PHBs are based on pre-configured limited forwarding capacity;=09 > traffic that exceeds that capacity may be shaped, remarked to a=09 > different DSCP, or dropped. >=20 > ######################################## >=20 > RFC3246 (three excerpts): >=20 > Packets belonging to a single microflow within the EF aggregate > passing through a device SHOULD NOT experience re-ordering in normal= > operation of the device. >=20 > Packets marked for EF PHB MAY be remarked at a DS domain boundary > only to other codepoints that satisfy the EF PHB. Packets marked fo= r > EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS > domain. >=20 > If the EF PHB is implemented by a mechanism that allows unlimited > preemption of other traffic (e.g., a priority queue), the > implementation MUST include some means to limit the damage EF traffi= c > could inflict on other traffic (e.g., a token bucket rate limiter). > Traffic that exceeds this limit MUST be discarded. >=20 >=20 >=20 >=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Ben Campbell > Gesendet: Samstag, 9. August 2014 19:50 > An: dart@ietf.org > Cc: Richard Barnes; draft-ietf-dart-dscp-rtp.all@tools.ietf.org; mls.ie= tf@gmail.com > Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >=20 > 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: >=20 > https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >=20 > 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 i= t's good to go, please say so. >=20 > Thanks! >=20 > Ben. >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart > . >=20 From nobody Tue Aug 12 00:38:38 2014 Return-Path: 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 7FDB91A0772; Tue, 12 Aug 2014 00:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MANGLED_BEEF=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 2IAInZo2BQ9q; Tue, 12 Aug 2014 00:38:31 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A047A1A0771; Tue, 12 Aug 2014 00:38:30 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail11.telekom.de with ESMTP; 12 Aug 2014 09:38:28 +0200 X-IronPort-AV: E=Sophos;i="5.01,847,1400018400"; d="scan'208";a="118910454" Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 12 Aug 2014 09:38:27 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 12 Aug 2014 09:38:27 +0200 From: To: Date: Tue, 12 Aug 2014 09:38:26 +0200 Thread-Topic: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 Thread-Index: Ac+1oKteIQhICmhbQ1SA6rD/HaR1EAAVuKCg Message-ID: References: <53E923CE.1000803@gmail.com> In-Reply-To: <53E923CE.1000803@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/NHlPypQnKgif3NnG-fhi6R7uR7o Cc: david.black@emc.com, dart@ietf.org, tsvwg@ietf.org Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 07:38:33 -0000 SGkgQnJpYW4sDQoNCndpdGggRUYgSSBsaW5rIGFuIGV4cGVjdGF0aW9uIG9mIGV4Y2VzcyB0cmFm ZmljIGJlaW5nIA0KZHJvcHBlZC4NCg0KQSByYXRlIHNjaGVkdWxlciB3aXRoIHNpbmdsZSBkaWdp dCBtaWxsaXNlY29uZCBidWZmZXIgDQpkZXB0aCBhbmQgdGFpbCBkcm9wIGxpa2UgYmVoYXZpb3Ig aXMgbm90IGFuIGlzc3VlLiANClRvIG1lLCB0aGF0J3MgYSBzaGFwZXIgY29uZmlndXJlZCB0byBi ZSBFRiBjb21wbGlhbnQuIA0KSWYgc3VjaCBhIGNvbnN0cmFpbnQgaXMgbm90IGRlc2lyZWQgdGhl biB0aGUgdGV4dCANCm1heSBzYXkgImlmIG1hcHBlZCB0byBhIG5vbi1FRiBQSEIsIGV4Y2VzcyB0 cmFmZmljIA0KbWF5IGJlIHNoYXBlZCIuIEknZCBsaWtlIHRvIGFzayBmb3Igc29tZSBleHBsYWlu aW5nIA0KdGV4dCBpZiBzaGFwaW5nIG9mIEVGIGV4Y2VzcyB0cmFmZmljIGlzIHJlZ2FyZGVkIA0K YXMgYSBwcm9wZXJ0eSB0byBiZSBleHBlY3RlZCBmb3IgdGhpcyBQSEIuDQoNCklmIGFuIEFGIGNs YXNzIGlzIHVzZWQgdG8gdHJhbnNwb3J0IEVGLCB0aGVuIGFueSBwb3RlbnRpYWwgDQpyZW1hcmtp bmcgc2hvdWxkIGJlIGRvbmUgaW4gYSB3YXkgYXZvaWRpbmcgcmUtb3JkZXJpbmcgDQooaS5lLiBy ZW1hcmsgdG8gRFNDUHMgd2l0aGluIHRoZSBzYW1lIEFGIGNsYXNzIG9ubHkpLiANClRoZXJlJ3Mg bm8gcG9pbnQgaW4gcmVtYXJraW5nIGV4Y2VzcyBFRiB0cmFmZmljIHRvIGEgUEhCIA0Kd2hpY2gg bWF5IGNhdXNlIHJlb3JkZXJpbmcuIEkgdGhpbmsgdGhhdCdzIHdoYXQgYSB0ZXh0IA0Kb24gcmVt YXJraW5nIG9mIEVGIHNob3VsZCBleHByZXNzLCBpZiByZW1hcmtpbmcgaXMgDQprZXB0IGFzIGFu IG9wdGlvbiB0byBiZSBleHBlY3RlZCAoSSd2ZSBub3QgeWV0IGhlYXJkIG9mIA0Kc3VjaCBhIGRl cGxveW1lbnQpLg0KDQpSZWdhcmRzLA0KDQpSdWVkaWdlcg0KDQoNCi0tLS0tVXJzcHLDvG5nbGlj aGUgTmFjaHJpY2h0LS0tLS0NClZvbjogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5l LmNhcnBlbnRlckBnbWFpbC5jb21dIA0KR2VzZW5kZXQ6IE1vbnRhZywgMTEuIEF1Z3VzdCAyMDE0 IDIyOjEzDQpBbjogR2VpYiwgUsO8ZGlnZXINCkNjOiBkYXZpZC5ibGFja0BlbWMuY29tOyBkYXJ0 QGlldGYub3JnOyB0c3Z3Z0BpZXRmLm9yZw0KQmV0cmVmZjogUmU6IFtEYXJ0XSBXR0xDOiBkcmFm dC1pZXRmLWRhcnQtZHNjcC1ydHAtMDINCg0KSGkgUnVlZGlnZXIsDQoNCk9uIDExLzA4LzIwMTQg MjI6MjEsIFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZSB3cm90ZToNCj4gSGkgRGF2aWQsDQo+IA0K PiBuZXcgRUYgcmVsYXRlZCB0ZXh0IGhhcyBiZWVuIGFkZGVkIGluIHRoZSAtMDEgdmVyc2lvbi4g SSd2ZSBjb3BpZWQgaW4gDQo+IHNvbWUgdGV4dCBvZiBSRkMzMjQ2IHJlbGF0ZWQgdG8gRUYgcmVt YXJraW5nIGFuZCBwb2xpY2luZyBiZWxvdy4NCj4gTXkgdGFrZToNCj4gDQo+IC4gcmVtYXJraW5n IG9mIGVudGlyZSBmbG93cyBpcyBhbiBvcHRpb24sIGJ1dCBubyByZW1hcmtpbmcgb2YgDQo+ICAg cGFja2V0cyBleGNlZWRpbmcgRUYgY2FwYWNpdHkgbGltaXRzLg0KPiAtIGxvb2tpbmcgYXQgdGhl IEVGIGppdHRlciBhbmQgZGVsYXkgcHJvcGVydGllcywgSSBkb3VidCB0aGF0IA0KPiAgIHNoYXBp bmcgaXMgZGVzaXJhYmxlLiBSRkMzMjQ2IGRvZXNuJ3QgbWVudGlvbiBzaGFwaW5nIGFzIHBhcnQg DQo+ICAgb2YgRUYgY29uZGl0aW9uaW5nLiBJIHBlcnNvbmFsbHkgd291bGRuJ3QgZXhwZWN0IEVG IHNoYXBpbmcgDQo+ICAgaW4gc2VjdGlvbnMgd2hlcmUgcG9saWNpbmcgaXMgYXBwbGllZC4gDQo+ IC0gZHJvcHBpbmcgb2YgcGFja2V0cyBleGNlZWRpbmcgRUYgY2FwYWNpdHkgaXMgYSBNVVNULCBp ZiBJIA0KPiAgIGludGVycHJldCBSRkMzMjQ2IGNvcnJlY3RseS4NCg0KV2VsbCwgaXQgc2VlbXMg dG8gbWUgdG8gYmUgYSBTSE9VTEQsIHdpdGggdGhlIE1VU1QgdGhhdCB5b3UgY2l0ZSBiZWxvdyBi ZWluZyBjb25kaXRpb25hbCBvbiAiYSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgdW5saW1pdGVkIHBy ZWVtcHRpb24gb2Ygb3RoZXIgdHJhZmZpYy4iIFNvIEkgd291bGQgbm90IGJlIGF0IGFsbCBzdXJw cmlzZWQgYnkgZGVwbG95bWVudHMgdGhhdCBzdXBwb3J0IHNoYXBpbmcgYW5kIHJlbWFya2luZy4g QWxzbywgdGhlcmUgYXJlIGNlcnRhaW5seSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhcmUgY2xvc2Vy IHRvIFJGQyAyNTk4IG9yIFJGQyAzMjQ4IGFuZCB0aGVyZWZvcmUgbGVzcyBzdHJpY3QuDQoNCkkg dGhpbmsgdGhlIGRyYWZ0IHNob3VsZCBtYWtlIGl0IGNsZWFyIHRoYXQgdGhlcmUgaXMgbGlrZWx5 IHRvIGJlIHZhcmlhdGlvbiBpbiBhY3R1YWwgYmVoYXZpb3VyIGZvciBFRiB0cmFmZmljIHRoYXQg ZXhjZWVkcyB0aGUgbm9taW5hbCByYXRlLiAoTGVhdmluZyBhc2lkZSB0aGUgZmFjdCB0aGF0IHdp dGhvdXQgYSBzdHJpbmcgb2YgbWF0Y2hpbmcgU0xBcyBhbG9uZyB0aGUgcGF0aCwgdGhlIG5vbWlu YWwgcmF0ZSBtaWdodCBub3QgZXZlbiBiZSB3ZWxsIGRlZmluZWQuKQ0KDQogICBCcmlhbg0KDQo+ IA0KPiBJIHN1Z2dlc3QgdG8gYWRhcHQgdGhlIHNlY3Rpb24gb2YgZHJhZnQtZGFydC1kc2NwIHRv IGJlIG1vcmUgcHJlY2lzZSANCj4gcmVnYXJkaW5nIHRoZSBvcHRpb25hbCByZW1hcmtpbmcgb2Yg RUYgdHJhZmZpYyBhbmQgdG8gcmVtb3ZlIHNoYXBpbmcgDQo+IGFzIGEgY29uZGl0aW9uaW5nIG9w dGlvbiBpZiB0cmFmZmljIGlzIGJleW9uZCB0aGUgRUYgZm9yd2FyZGluZyANCj4gY2FwYWNpdHkg bGltaXQuIEEgUHJvcG9zYWwgZm9yIHRoZSBmaW5hbA0KPiBzZW50ZW5jZToNCj4gDQo+IC4uLmV4 Y2VlZHMgdGhhdCBjYXBhY2l0eSBtdXN0IGJlIGRyb3BwZWQuIEVGIGNvbXBsaWFudCBmbG93cyBt YXkgYmUgDQo+IHJlbWFya2VkIHRvIGEgZGlmZmVyZW50IERTQ1AuDQo+IA0KPiBBbGwgb3RoZXIg bmV3IHRleHQgaW5kaWNhdGVkIGJ5IHRoZSBEaWZmIHZlcnNpb24gbG9va3MgYWxscmlnaHQuDQo+ IA0KPiBSZWdhcmRzLA0KPiANCj4gUnVlZGlnZXINCj4gDQo+IA0KPiANCj4gZHJhZnQtZGFydC1k c2NwOg0KPiANCj4gMy4gRXhwZWRpdGVkIEZvcndhcmRpbmcgKEVGKSBbUkZDMzI0Nl0gaW50ZW5k ZWQgZm9yIGluZWxhc3RpYwkNCj4gICAgdHJhZmZpYy4gQmV5b25kIHRoZSBiYXNpYyBFRiBQSEIs IHRoZSBWT0lDRS1BRE1JVCBQSEIgW1JGQzU4NjVdCQ0KPiAgICBpcyBhbiBhZG1pc3Npb24gY29u dHJvbGxlZCB2YXJpYW50IG9mIHRoZSBFRiBQSEIuIEJvdGggb2YgdGhlc2UJDQo+ICAgIFBIQnMg YXJlIGJhc2VkIG9uIHByZS1jb25maWd1cmVkIGxpbWl0ZWQgZm9yd2FyZGluZyBjYXBhY2l0eTsJ DQo+ICAgIHRyYWZmaWMgdGhhdCBleGNlZWRzIHRoYXQgY2FwYWNpdHkgbWF5IGJlIHNoYXBlZCwg cmVtYXJrZWQgdG8gYQkNCj4gICAgZGlmZmVyZW50IERTQ1AsIG9yIGRyb3BwZWQuDQo+IA0KPiAj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQo+IA0KPiBSRkMzMjQ2ICh0 aHJlZSBleGNlcnB0cyk6DQo+IA0KPiAgICBQYWNrZXRzIGJlbG9uZ2luZyB0byBhIHNpbmdsZSBt aWNyb2Zsb3cgd2l0aGluIHRoZSBFRiBhZ2dyZWdhdGUNCj4gICAgcGFzc2luZyB0aHJvdWdoIGEg ZGV2aWNlIFNIT1VMRCBOT1QgZXhwZXJpZW5jZSByZS1vcmRlcmluZyBpbiBub3JtYWwNCj4gICAg b3BlcmF0aW9uIG9mIHRoZSBkZXZpY2UuDQo+IA0KPiAgICBQYWNrZXRzIG1hcmtlZCBmb3IgRUYg UEhCIE1BWSBiZSByZW1hcmtlZCBhdCBhIERTIGRvbWFpbiBib3VuZGFyeQ0KPiAgICBvbmx5IHRv IG90aGVyIGNvZGVwb2ludHMgdGhhdCBzYXRpc2Z5IHRoZSBFRiBQSEIuICBQYWNrZXRzIG1hcmtl ZCBmb3INCj4gICAgRUYgUEhCcyBTSE9VTEQgTk9UIGJlIGRlbW90ZWQgb3IgcHJvbW90ZWQgdG8g YW5vdGhlciBQSEIgYnkgYSBEUw0KPiAgICBkb21haW4uDQo+IA0KPiAgICBJZiB0aGUgRUYgUEhC IGlzIGltcGxlbWVudGVkIGJ5IGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIHVubGltaXRlZA0KPiAg ICBwcmVlbXB0aW9uIG9mIG90aGVyIHRyYWZmaWMgKGUuZy4sIGEgcHJpb3JpdHkgcXVldWUpLCB0 aGUNCj4gICAgaW1wbGVtZW50YXRpb24gTVVTVCBpbmNsdWRlIHNvbWUgbWVhbnMgdG8gbGltaXQg dGhlIGRhbWFnZSBFRiB0cmFmZmljDQo+ICAgIGNvdWxkIGluZmxpY3Qgb24gb3RoZXIgdHJhZmZp YyAoZS5nLiwgYSB0b2tlbiBidWNrZXQgcmF0ZSBsaW1pdGVyKS4NCj4gICAgVHJhZmZpYyB0aGF0 IGV4Y2VlZHMgdGhpcyBsaW1pdCBNVVNUIGJlIGRpc2NhcmRlZC4NCj4gDQo+IA0KPiANCj4gDQo+ IA0KPiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+IFZvbjogRGFydCBbbWFp bHRvOmRhcnQtYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gQmVuIENhbXBiZWxsDQo+ IEdlc2VuZGV0OiBTYW1zdGFnLCA5LiBBdWd1c3QgMjAxNCAxOTo1MA0KPiBBbjogZGFydEBpZXRm Lm9yZw0KPiBDYzogUmljaGFyZCBCYXJuZXM7IGRyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cC5hbGxA dG9vbHMuaWV0Zi5vcmc7IA0KPiBtbHMuaWV0ZkBnbWFpbC5jb20NCj4gQmV0cmVmZjogW0RhcnRd IFdHTEM6IGRyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cC0wMg0KPiANCj4gVGhpcyBpcyBhIERBUlQg V29ya2luZyBHcm91cCBMYXN0IENhbGwgb2YgZHJhZnQtaWV0Zi1kYXJ0LWRzY3AtcnRwLTAyLiBJ dCdzIGF2YWlsYWJsZSBvbiB0aGUgZGF0YSB0cmFja2VyIGF0IHRoZSBmb2xsb3dpbmcgVVJMOg0K PiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kYXJ0LWRz Y3AtcnRwLw0KPiANCj4gVGhlIFdHTEMgd2lsbCBjb25jbHVkZSBvbiAyMiBBdWd1c3QsIDIwMTQu IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGF1dGhvcnMgYW5kIHRoZSBEQVJUIG1h aWxpbmcgbGlzdC4gSWYgeW91J3ZlIHJldmlld2VkIGl0IGFuZCB0aGluayBpdCdzIGdvb2QgdG8g Z28sIHBsZWFzZSBzYXkgc28uDQo+IA0KPiBUaGFua3MhDQo+IA0KPiBCZW4uDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEYXJ0IG1haWxp bmcgbGlzdA0KPiBEYXJ0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGFydA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gRGFydCBtYWlsaW5nIGxpc3QNCj4gRGFydEBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RhcnQNCj4gLg0KPiANCg0K From nobody Tue Aug 12 13:35:25 2014 Return-Path: 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 47B041A0009; Tue, 12 Aug 2014 13:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_BEEF=2.3, SPF_PASS=-0.001] autolearn=no 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 aafDgaDZJhjg; Tue, 12 Aug 2014 13:35:15 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E051A0005; Tue, 12 Aug 2014 13:35:15 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rd3so13655701pab.28 for ; Tue, 12 Aug 2014 13:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZzAqtJwtG2OYu0b2l4XLO9uvXuseLXSHge7+UuboxQ8=; b=pTtTgA80aE3TmJUNgCLIXZxlzNhDg7RBbYfEEd/tqmgaGsOqSnroTLWdag2u4IZmsM h9OYx5hVx94RElxC6X/jFfkl1e/vOno61PPoDfjcvFMf4nhkR4ATDJx9lkjd07YHV546 RRDV7BEkg6OlW3MOSxrTmAezQl5efGeXnRRw9nPCAkAedmnsKQmYjYQUWANVmMvL3kNC R4lpag4pcVIc4h41R+uvyaooexT2FiaOcXSDrcTfYo14DrweuEz/KFblcVJkeYGVCt+3 UsjhNo3GOiIITPbm4/qO95VhMvu3Pk74dGcyT/iqE6PxeKM4itEjVQVwNPpVGUy+JIpP 3Ncw== X-Received: by 10.68.139.162 with SMTP id qz2mr3423309pbb.153.1407875714300; Tue, 12 Aug 2014 13:35:14 -0700 (PDT) Received: from [192.168.178.23] (19.198.69.111.dynamic.snap.net.nz. [111.69.198.19]) by mx.google.com with ESMTPSA id am3sm15499652pbd.18.2014.08.12.13.35.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Aug 2014 13:35:13 -0700 (PDT) Message-ID: <53EA7A80.6010800@gmail.com> Date: Wed, 13 Aug 2014 08:35:12 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <53E923CE.1000803@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dart/oHyAEPRetXTN_zRaEyqWkODO2pg Cc: david.black@emc.com, dart@ietf.org, tsvwg@ietf.org Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 20:35:20 -0000 Hi Ruediger, On 12/08/2014 19:38, Ruediger.Geib@telekom.de wrote: > Hi Brian, >=20 > with EF I link an expectation of excess traffic being=20 > dropped. In general I agree; but that only makes sense if there is an agreement (or mechanism) to define the nominal rate, and rate control of some kind at the source. (An IP phone is in effect a rate controller, for example.) >=20 > A rate scheduler with single digit millisecond buffer=20 > depth and tail drop like behavior is not an issue.=20 > To me, that's a shaper configured to be EF compliant.=20 > If such a constraint is not desired then the text=20 > may say "if mapped to a non-EF PHB, excess traffic=20 > may be shaped". I'd like to ask for some explaining=20 > text if shaping of EF excess traffic is regarded=20 > as a property to be expected for this PHB. Yes, technically that's correct - but a shaper could be inserted at the boundary between two DS domains, and for the end-to-end user that will appear as a property of the PHB. > If an AF class is used to transport EF, then any potential=20 > remarking should be done in a way avoiding re-ordering=20 > (i.e. remark to DSCPs within the same AF class only).=20 > There's no point in remarking excess EF traffic to a PHB=20 > which may cause reordering.=20 I fully agree. > I think that's what a text=20 > on remarking of EF should express, if remarking is=20 > kept as an option to be expected (I've not yet heard of=20 > such a deployment). Yes. I'm not advocating such behaviour; my point is only that EF may not always be strictly conformant to RFC 3246. Brian > Regards, >=20 > Ruediger >=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > Gesendet: Montag, 11. August 2014 22:13 > An: Geib, R=C3=BCdiger > Cc: david.black@emc.com; dart@ietf.org; tsvwg@ietf.org > Betreff: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >=20 > Hi Ruediger, >=20 > On 11/08/2014 22:21, Ruediger.Geib@telekom.de wrote: >> Hi David, >> >> new EF related text has been added in the -01 version. I've copied in = >> some text of RFC3246 related to EF remarking and policing below. >> My take: >> >> . remarking of entire flows is an option, but no remarking of=20 >> packets exceeding EF capacity limits. >> - looking at the EF jitter and delay properties, I doubt that=20 >> shaping is desirable. RFC3246 doesn't mention shaping as part=20 >> of EF conditioning. I personally wouldn't expect EF shaping=20 >> in sections where policing is applied.=20 >> - dropping of packets exceeding EF capacity is a MUST, if I=20 >> interpret RFC3246 correctly. >=20 > Well, it seems to me to be a SHOULD, with the MUST that you cite below = being conditional on "a mechanism that allows unlimited preemption of oth= er traffic." So I would not be at all surprised by deployments that suppo= rt shaping and remarking. Also, there are certainly implementations that = are closer to RFC 2598 or RFC 3248 and therefore less strict. >=20 > I think the draft should make it clear that there is likely to be varia= tion in actual behaviour for EF traffic that exceeds the nominal rate. (L= eaving aside the fact that without a string of matching SLAs along the pa= th, the nominal rate might not even be well defined.) >=20 > Brian >=20 >> I suggest to adapt the section of draft-dart-dscp to be more precise=20 >> regarding the optional remarking of EF traffic and to remove shaping=20 >> as a conditioning option if traffic is beyond the EF forwarding=20 >> capacity limit. A Proposal for the final >> sentence: >> >> ...exceeds that capacity must be dropped. EF compliant flows may be=20 >> remarked to a different DSCP. >> >> All other new text indicated by the Diff version looks allright. >> >> Regards, >> >> Ruediger >> >> >> >> draft-dart-dscp: >> >> 3. Expedited Forwarding (EF) [RFC3246] intended for inelastic=09 >> traffic. Beyond the basic EF PHB, the VOICE-ADMIT PHB [RFC5865]=09 >> is an admission controlled variant of the EF PHB. Both of these=09 >> PHBs are based on pre-configured limited forwarding capacity;=09 >> traffic that exceeds that capacity may be shaped, remarked to a=09 >> different DSCP, or dropped. >> >> ######################################## >> >> RFC3246 (three excerpts): >> >> Packets belonging to a single microflow within the EF aggregate >> passing through a device SHOULD NOT experience re-ordering in norma= l >> operation of the device. >> >> Packets marked for EF PHB MAY be remarked at a DS domain boundary >> only to other codepoints that satisfy the EF PHB. Packets marked f= or >> EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS >> domain. >> >> If the EF PHB is implemented by a mechanism that allows unlimited >> preemption of other traffic (e.g., a priority queue), the >> implementation MUST include some means to limit the damage EF traff= ic >> could inflict on other traffic (e.g., a token bucket rate limiter).= >> Traffic that exceeds this limit MUST be discarded. >> >> >> >> >> >> -----Urspr=C3=BCngliche Nachricht----- >> Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Ben Campbell >> Gesendet: Samstag, 9. August 2014 19:50 >> An: dart@ietf.org >> Cc: Richard Barnes; draft-ietf-dart-dscp-rtp.all@tools.ietf.org;=20 >> mls.ietf@gmail.com >> Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >> >> 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 t= o the authors and the DART mailing list. If you've reviewed it and think = it's good to go, please say so. >> >> Thanks! >> >> Ben. >> >> _______________________________________________ >> Dart mailing list >> Dart@ietf.org >> https://www.ietf.org/mailman/listinfo/dart >> >> _______________________________________________ >> Dart mailing list >> Dart@ietf.org >> https://www.ietf.org/mailman/listinfo/dart >> . >> >=20 From nobody Tue Aug 12 18:43:20 2014 Return-Path: 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 D35DD1A6FAB for ; Tue, 12 Aug 2014 18:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 KrA9ZBaqPkeS for ; Tue, 12 Aug 2014 18:43:16 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3AF1A002A for ; Tue, 12 Aug 2014 18:43:16 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j17so8003256oag.28 for ; Tue, 12 Aug 2014 18:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=NwSgENbDchpv85jwtVPNFTepD2piNm8QKS2cCgcn3P4=; b=A5Vs6ksIZk41/Xl9EhYeMgCfB68/4LoQfUeC8XzuHncS9UfS0mknrGDX9F8zeCAvSc xi9gyhYvg8p6Doh3tFORWZNirBgXCe5zyc+QPci9I8VeTi/t1jIVIKVXIfAmvXka8Slk 6Fzmu8KNnCpA9r9p9LzMhrsv6lcp8ZbPZFvosGlrCqf+OWrTBHcjaM/c1um27aqkovnl MDPGGrjvKUVTUFb/6U/1lHVvKiqQrno8Nn96EwODKql7Bred6NlBPyilSwmHnhu/FPZL F/mRk7tVnqcVneqLal6Ypl63ULgHAOqnzQel4AVll6dUVUQY1kt5uhSF8yxuifr3JXRT F3jg== MIME-Version: 1.0 X-Received: by 10.60.58.65 with SMTP id o1mr1656774oeq.2.1407894195639; Tue, 12 Aug 2014 18:43:15 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Tue, 12 Aug 2014 18:43:15 -0700 (PDT) Date: Tue, 12 Aug 2014 18:43:15 -0700 Message-ID: From: Dave Taht To: dart@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dart/saQjRoQ-xIA4IN2FxqKq36zTxEk Subject: Re: [Dart] [rtcweb] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 01:43:17 -0000 This is also of some interest to me at least, and perhaps some members of the AQM working group who are working out weighted fair queuing and wred like approaches to these needs. Anyway, I do try to track thinking in this area in the ongoing development of cerowrt's sqm system, which has pluggable modules for all the known aqm and fq schedulers, and a three tier system modeled on wondershaper for managing traffic, which uses what diffserv markings that I have observed make sense... Some relevant links: http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt= _310 http://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management Missing from this discussion so far is what is actually deployed out there... I am only familiar with stuff like the above as an egress/ingress queue management system... AND: in the case of linux based wireless routers, none of the AF codepoints are respected explicitly, and how the codepoints are mapped are described by 802.11e - and that is far more about scheduling priority for airtime rather than drop probability. It is kind of hard to wrap your head around how 802.11e actually works, but, this is a start: http://en.wikipedia.org/wiki/IEEE_802.11e-2005#Enhanced_distributed_channel= _access_.28EDCA.29 In linux wifi at least: CS0, CS3 are mapped into the BE hw queue CS1, CS2 are mapped into the BK hw queue CS4, CS5 are mapped into the VI hw queue CS6, CS7 are mapped into the VO hw queue Bit patterns for the other classes to whatever extent they map into CSX are mapped into the underlying hardware queue. I am not saying this is an optimal state of affairs, (as notably VO should be as completely disabled as possible in the 802.11n and ac age), and am very interested in how other OSes (ios, osx, windows), and router/switch OSes do it, but the wireless scheduling aspect of all these codepoints does not seem to be well touched upon. On a personal note I tend to think that having 17+ ways to slice up traffic is about 13 or 14 too many, particularly those targetting a drop probability. When you have drop rates well below a few percentage points, adding another percentage point of granularity seems futile. Lastly, there is also an implementation issue in linux presently in that doing extensive diffserv classification basically requires one iptables or tc rule per class, which is inefficient. Someone (not me!) doing some code for doing diffserv saner there would go a long way... --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Tue Aug 12 23:39:46 2014 Return-Path: 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 E24141A6FFF; Tue, 12 Aug 2014 23:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MANGLED_BEEF=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 jSksI0OObaQU; Tue, 12 Aug 2014 23:39:40 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4636D1A6FFA; Tue, 12 Aug 2014 23:39:39 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 13 Aug 2014 08:39:37 +0200 X-IronPort-AV: E=Sophos;i="5.01,855,1400018400"; d="scan'208";a="513890320" Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 13 Aug 2014 08:39:37 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 13 Aug 2014 08:39:36 +0200 From: To: Date: Wed, 13 Aug 2014 08:39:36 +0200 Thread-Topic: AW: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 Thread-Index: Ac+2bO5f3WR7i7TTT2C8E/wL7+YxHAAUuAdQ Message-ID: References: <53E923CE.1000803@gmail.com> <53EA7A80.6010800@gmail.com> In-Reply-To: <53EA7A80.6010800@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/GB8N3PrzMdjzrLDlxakZWsnVlIM Cc: david.black@emc.com, dart@ietf.org, tsvwg@ietf.org Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 06:39:44 -0000 SGkgQnJpYW4sDQoNCndlIGFyZSBpbiBhZ3JlZW1lbnQgaW4gbW9zdCBwb2ludHMuIA0KDQpPZiBj b3Vyc2UgYSBwcm92aWRlciBjb3VsZCBzaGFwZSBFRiB0cmFmZmljIG9uIGFuIA0KaW50ZXJjb25u ZWN0aW9uLiBUaGlzIG1heSBub3QgYmUgYSBzb2x1dGlvbiB3aGljaCANCkkgZmF2b3IsIGJ1dCBp dCBpcyBwb3NzaWJsZS4gDQoNClJlZ2FyZHMsDQoNClJ1ZWRpZ2VyDQoNCi0tLS0tVXJzcHLDvG5n bGljaGUgTmFjaHJpY2h0LS0tLS0NClZvbjogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb21dIA0KR2VzZW5kZXQ6IERpZW5zdGFnLCAxMi4gQXVndXN0 IDIwMTQgMjI6MzUNCkFuOiBHZWliLCBSw7xkaWdlcg0KQ2M6IGRhdmlkLmJsYWNrQGVtYy5jb207 IGRhcnRAaWV0Zi5vcmc7IHRzdndnQGlldGYub3JnDQpCZXRyZWZmOiBSZTogQVc6IFtEYXJ0XSBX R0xDOiBkcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAtMDINCg0KSGkgUnVlZGlnZXIsDQoNCk9uIDEy LzA4LzIwMTQgMTk6MzgsIFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZSB3cm90ZToNCj4gSGkgQnJp YW4sDQo+IA0KPiB3aXRoIEVGIEkgbGluayBhbiBleHBlY3RhdGlvbiBvZiBleGNlc3MgdHJhZmZp YyBiZWluZyBkcm9wcGVkLg0KDQpJbiBnZW5lcmFsIEkgYWdyZWU7IGJ1dCB0aGF0IG9ubHkgbWFr ZXMgc2Vuc2UgaWYgdGhlcmUgaXMgYW4gYWdyZWVtZW50IChvciBtZWNoYW5pc20pIHRvIGRlZmlu ZSB0aGUgbm9taW5hbCByYXRlLCBhbmQgcmF0ZSBjb250cm9sIG9mIHNvbWUga2luZCBhdCB0aGUg c291cmNlLiAoQW4gSVAgcGhvbmUgaXMgaW4gZWZmZWN0IGEgcmF0ZSBjb250cm9sbGVyLCBmb3Ig ZXhhbXBsZS4pDQoNCj4gDQo+IEEgcmF0ZSBzY2hlZHVsZXIgd2l0aCBzaW5nbGUgZGlnaXQgbWls bGlzZWNvbmQgYnVmZmVyIGRlcHRoIGFuZCB0YWlsIA0KPiBkcm9wIGxpa2UgYmVoYXZpb3IgaXMg bm90IGFuIGlzc3VlLg0KPiBUbyBtZSwgdGhhdCdzIGEgc2hhcGVyIGNvbmZpZ3VyZWQgdG8gYmUg RUYgY29tcGxpYW50LiANCj4gSWYgc3VjaCBhIGNvbnN0cmFpbnQgaXMgbm90IGRlc2lyZWQgdGhl biB0aGUgdGV4dCBtYXkgc2F5ICJpZiBtYXBwZWQgDQo+IHRvIGEgbm9uLUVGIFBIQiwgZXhjZXNz IHRyYWZmaWMgbWF5IGJlIHNoYXBlZCIuIEknZCBsaWtlIHRvIGFzayBmb3IgDQo+IHNvbWUgZXhw bGFpbmluZyB0ZXh0IGlmIHNoYXBpbmcgb2YgRUYgZXhjZXNzIHRyYWZmaWMgaXMgcmVnYXJkZWQg YXMgYSANCj4gcHJvcGVydHkgdG8gYmUgZXhwZWN0ZWQgZm9yIHRoaXMgUEhCLg0KDQpZZXMsIHRl Y2huaWNhbGx5IHRoYXQncyBjb3JyZWN0IC0gYnV0IGEgc2hhcGVyIGNvdWxkIGJlIGluc2VydGVk IGF0IHRoZSBib3VuZGFyeSBiZXR3ZWVuIHR3byBEUyBkb21haW5zLCBhbmQgZm9yIHRoZSBlbmQt dG8tZW5kIHVzZXIgdGhhdCB3aWxsIGFwcGVhciBhcyBhIHByb3BlcnR5IG9mIHRoZSBQSEIuDQoN Cj4gSWYgYW4gQUYgY2xhc3MgaXMgdXNlZCB0byB0cmFuc3BvcnQgRUYsIHRoZW4gYW55IHBvdGVu dGlhbCByZW1hcmtpbmcgDQo+IHNob3VsZCBiZSBkb25lIGluIGEgd2F5IGF2b2lkaW5nIHJlLW9y ZGVyaW5nIChpLmUuIHJlbWFyayB0byBEU0NQcyANCj4gd2l0aGluIHRoZSBzYW1lIEFGIGNsYXNz IG9ubHkpLg0KPiBUaGVyZSdzIG5vIHBvaW50IGluIHJlbWFya2luZyBleGNlc3MgRUYgdHJhZmZp YyB0byBhIFBIQiB3aGljaCBtYXkgDQo+IGNhdXNlIHJlb3JkZXJpbmcuDQoNCkkgZnVsbHkgYWdy ZWUuDQoNCj4gSSB0aGluayB0aGF0J3Mgd2hhdCBhIHRleHQNCj4gb24gcmVtYXJraW5nIG9mIEVG IHNob3VsZCBleHByZXNzLCBpZiByZW1hcmtpbmcgaXMga2VwdCBhcyBhbiBvcHRpb24gDQo+IHRv IGJlIGV4cGVjdGVkIChJJ3ZlIG5vdCB5ZXQgaGVhcmQgb2Ygc3VjaCBhIGRlcGxveW1lbnQpLg0K DQpZZXMuIEknbSBub3QgYWR2b2NhdGluZyBzdWNoIGJlaGF2aW91cjsgbXkgcG9pbnQgaXMgb25s eSB0aGF0IEVGIG1heSBub3QgYWx3YXlzIGJlIHN0cmljdGx5IGNvbmZvcm1hbnQgdG8gUkZDIDMy NDYuDQoNCiAgIEJyaWFuDQoNCj4gUmVnYXJkcywNCj4gDQo+IFJ1ZWRpZ2VyDQo+IA0KPiANCj4g LS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246IEJyaWFuIEUgQ2FycGVu dGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiBHZXNlbmRldDogTW9u dGFnLCAxMS4gQXVndXN0IDIwMTQgMjI6MTMNCj4gQW46IEdlaWIsIFLDvGRpZ2VyDQo+IENjOiBk YXZpZC5ibGFja0BlbWMuY29tOyBkYXJ0QGlldGYub3JnOyB0c3Z3Z0BpZXRmLm9yZw0KPiBCZXRy ZWZmOiBSZTogW0RhcnRdIFdHTEM6IGRyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cC0wMg0KPiANCj4g SGkgUnVlZGlnZXIsDQo+IA0KPiBPbiAxMS8wOC8yMDE0IDIyOjIxLCBSdWVkaWdlci5HZWliQHRl bGVrb20uZGUgd3JvdGU6DQo+PiBIaSBEYXZpZCwNCj4+DQo+PiBuZXcgRUYgcmVsYXRlZCB0ZXh0 IGhhcyBiZWVuIGFkZGVkIGluIHRoZSAtMDEgdmVyc2lvbi4gSSd2ZSBjb3BpZWQgaW4gDQo+PiBz b21lIHRleHQgb2YgUkZDMzI0NiByZWxhdGVkIHRvIEVGIHJlbWFya2luZyBhbmQgcG9saWNpbmcg YmVsb3cuDQo+PiBNeSB0YWtlOg0KPj4NCj4+IC4gcmVtYXJraW5nIG9mIGVudGlyZSBmbG93cyBp cyBhbiBvcHRpb24sIGJ1dCBubyByZW1hcmtpbmcgb2YgDQo+PiAgIHBhY2tldHMgZXhjZWVkaW5n IEVGIGNhcGFjaXR5IGxpbWl0cy4NCj4+IC0gbG9va2luZyBhdCB0aGUgRUYgaml0dGVyIGFuZCBk ZWxheSBwcm9wZXJ0aWVzLCBJIGRvdWJ0IHRoYXQgDQo+PiAgIHNoYXBpbmcgaXMgZGVzaXJhYmxl LiBSRkMzMjQ2IGRvZXNuJ3QgbWVudGlvbiBzaGFwaW5nIGFzIHBhcnQgDQo+PiAgIG9mIEVGIGNv bmRpdGlvbmluZy4gSSBwZXJzb25hbGx5IHdvdWxkbid0IGV4cGVjdCBFRiBzaGFwaW5nIA0KPj4g ICBpbiBzZWN0aW9ucyB3aGVyZSBwb2xpY2luZyBpcyBhcHBsaWVkLiANCj4+IC0gZHJvcHBpbmcg b2YgcGFja2V0cyBleGNlZWRpbmcgRUYgY2FwYWNpdHkgaXMgYSBNVVNULCBpZiBJIA0KPj4gICBp bnRlcnByZXQgUkZDMzI0NiBjb3JyZWN0bHkuDQo+IA0KPiBXZWxsLCBpdCBzZWVtcyB0byBtZSB0 byBiZSBhIFNIT1VMRCwgd2l0aCB0aGUgTVVTVCB0aGF0IHlvdSBjaXRlIGJlbG93IGJlaW5nIGNv bmRpdGlvbmFsIG9uICJhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyB1bmxpbWl0ZWQgcHJlZW1wdGlv biBvZiBvdGhlciB0cmFmZmljLiIgU28gSSB3b3VsZCBub3QgYmUgYXQgYWxsIHN1cnByaXNlZCBi eSBkZXBsb3ltZW50cyB0aGF0IHN1cHBvcnQgc2hhcGluZyBhbmQgcmVtYXJraW5nLiBBbHNvLCB0 aGVyZSBhcmUgY2VydGFpbmx5IGltcGxlbWVudGF0aW9ucyB0aGF0IGFyZSBjbG9zZXIgdG8gUkZD IDI1OTggb3IgUkZDIDMyNDggYW5kIHRoZXJlZm9yZSBsZXNzIHN0cmljdC4NCj4gDQo+IEkgdGhp bmsgdGhlIGRyYWZ0IHNob3VsZCBtYWtlIGl0IGNsZWFyIHRoYXQgdGhlcmUgaXMgbGlrZWx5IHRv IGJlIA0KPiB2YXJpYXRpb24gaW4gYWN0dWFsIGJlaGF2aW91ciBmb3IgRUYgdHJhZmZpYyB0aGF0 IGV4Y2VlZHMgdGhlIG5vbWluYWwgDQo+IHJhdGUuIChMZWF2aW5nIGFzaWRlIHRoZSBmYWN0IHRo YXQgd2l0aG91dCBhIHN0cmluZyBvZiBtYXRjaGluZyBTTEFzIA0KPiBhbG9uZyB0aGUgcGF0aCwg dGhlIG5vbWluYWwgcmF0ZSBtaWdodCBub3QgZXZlbiBiZSB3ZWxsIGRlZmluZWQuKQ0KPiANCj4g ICAgQnJpYW4NCj4gDQo+PiBJIHN1Z2dlc3QgdG8gYWRhcHQgdGhlIHNlY3Rpb24gb2YgZHJhZnQt ZGFydC1kc2NwIHRvIGJlIG1vcmUgcHJlY2lzZSANCj4+IHJlZ2FyZGluZyB0aGUgb3B0aW9uYWwg cmVtYXJraW5nIG9mIEVGIHRyYWZmaWMgYW5kIHRvIHJlbW92ZSBzaGFwaW5nIA0KPj4gYXMgYSBj b25kaXRpb25pbmcgb3B0aW9uIGlmIHRyYWZmaWMgaXMgYmV5b25kIHRoZSBFRiBmb3J3YXJkaW5n IA0KPj4gY2FwYWNpdHkgbGltaXQuIEEgUHJvcG9zYWwgZm9yIHRoZSBmaW5hbA0KPj4gc2VudGVu Y2U6DQo+Pg0KPj4gLi4uZXhjZWVkcyB0aGF0IGNhcGFjaXR5IG11c3QgYmUgZHJvcHBlZC4gRUYg Y29tcGxpYW50IGZsb3dzIG1heSBiZSANCj4+IHJlbWFya2VkIHRvIGEgZGlmZmVyZW50IERTQ1Au DQo+Pg0KPj4gQWxsIG90aGVyIG5ldyB0ZXh0IGluZGljYXRlZCBieSB0aGUgRGlmZiB2ZXJzaW9u IGxvb2tzIGFsbHJpZ2h0Lg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gUnVlZGlnZXINCj4+DQo+ Pg0KPj4NCj4+IGRyYWZ0LWRhcnQtZHNjcDoNCj4+DQo+PiAzLiBFeHBlZGl0ZWQgRm9yd2FyZGlu ZyAoRUYpIFtSRkMzMjQ2XSBpbnRlbmRlZCBmb3IgaW5lbGFzdGljCQ0KPj4gICAgdHJhZmZpYy4g QmV5b25kIHRoZSBiYXNpYyBFRiBQSEIsIHRoZSBWT0lDRS1BRE1JVCBQSEIgW1JGQzU4NjVdCQ0K Pj4gICAgaXMgYW4gYWRtaXNzaW9uIGNvbnRyb2xsZWQgdmFyaWFudCBvZiB0aGUgRUYgUEhCLiBC b3RoIG9mIHRoZXNlCQ0KPj4gICAgUEhCcyBhcmUgYmFzZWQgb24gcHJlLWNvbmZpZ3VyZWQgbGlt aXRlZCBmb3J3YXJkaW5nIGNhcGFjaXR5OwkNCj4+ICAgIHRyYWZmaWMgdGhhdCBleGNlZWRzIHRo YXQgY2FwYWNpdHkgbWF5IGJlIHNoYXBlZCwgcmVtYXJrZWQgdG8gYQkNCj4+ICAgIGRpZmZlcmVu dCBEU0NQLCBvciBkcm9wcGVkLg0KPj4NCj4+ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMNCj4+DQo+PiBSRkMzMjQ2ICh0aHJlZSBleGNlcnB0cyk6DQo+Pg0KPj4gICAg UGFja2V0cyBiZWxvbmdpbmcgdG8gYSBzaW5nbGUgbWljcm9mbG93IHdpdGhpbiB0aGUgRUYgYWdn cmVnYXRlDQo+PiAgICBwYXNzaW5nIHRocm91Z2ggYSBkZXZpY2UgU0hPVUxEIE5PVCBleHBlcmll bmNlIHJlLW9yZGVyaW5nIGluIG5vcm1hbA0KPj4gICAgb3BlcmF0aW9uIG9mIHRoZSBkZXZpY2Uu DQo+Pg0KPj4gICAgUGFja2V0cyBtYXJrZWQgZm9yIEVGIFBIQiBNQVkgYmUgcmVtYXJrZWQgYXQg YSBEUyBkb21haW4gYm91bmRhcnkNCj4+ICAgIG9ubHkgdG8gb3RoZXIgY29kZXBvaW50cyB0aGF0 IHNhdGlzZnkgdGhlIEVGIFBIQi4gIFBhY2tldHMgbWFya2VkIGZvcg0KPj4gICAgRUYgUEhCcyBT SE9VTEQgTk9UIGJlIGRlbW90ZWQgb3IgcHJvbW90ZWQgdG8gYW5vdGhlciBQSEIgYnkgYSBEUw0K Pj4gICAgZG9tYWluLg0KPj4NCj4+ICAgIElmIHRoZSBFRiBQSEIgaXMgaW1wbGVtZW50ZWQgYnkg YSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgdW5saW1pdGVkDQo+PiAgICBwcmVlbXB0aW9uIG9mIG90 aGVyIHRyYWZmaWMgKGUuZy4sIGEgcHJpb3JpdHkgcXVldWUpLCB0aGUNCj4+ICAgIGltcGxlbWVu dGF0aW9uIE1VU1QgaW5jbHVkZSBzb21lIG1lYW5zIHRvIGxpbWl0IHRoZSBkYW1hZ2UgRUYgdHJh ZmZpYw0KPj4gICAgY291bGQgaW5mbGljdCBvbiBvdGhlciB0cmFmZmljIChlLmcuLCBhIHRva2Vu IGJ1Y2tldCByYXRlIGxpbWl0ZXIpLg0KPj4gICAgVHJhZmZpYyB0aGF0IGV4Y2VlZHMgdGhpcyBs aW1pdCBNVVNUIGJlIGRpc2NhcmRlZC4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gLS0tLS1VcnNw csO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPj4gVm9uOiBEYXJ0IFttYWlsdG86ZGFydC1ib3Vu Y2VzQGlldGYub3JnXSBJbSBBdWZ0cmFnIHZvbiBCZW4gQ2FtcGJlbGwNCj4+IEdlc2VuZGV0OiBT YW1zdGFnLCA5LiBBdWd1c3QgMjAxNCAxOTo1MA0KPj4gQW46IGRhcnRAaWV0Zi5vcmcNCj4+IENj OiBSaWNoYXJkIEJhcm5lczsgZHJhZnQtaWV0Zi1kYXJ0LWRzY3AtcnRwLmFsbEB0b29scy5pZXRm Lm9yZzsNCj4+IG1scy5pZXRmQGdtYWlsLmNvbQ0KPj4gQmV0cmVmZjogW0RhcnRdIFdHTEM6IGRy YWZ0LWlldGYtZGFydC1kc2NwLXJ0cC0wMg0KPj4NCj4+IFRoaXMgaXMgYSBEQVJUIFdvcmtpbmcg R3JvdXAgTGFzdCBDYWxsIG9mIGRyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cC0wMi4gSXQncyBhdmFp bGFibGUgb24gdGhlIGRhdGEgdHJhY2tlciBhdCB0aGUgZm9sbG93aW5nIFVSTDoNCj4+DQo+PiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAv DQo+Pg0KPj4gVGhlIFdHTEMgd2lsbCBjb25jbHVkZSBvbiAyMiBBdWd1c3QsIDIwMTQuIFBsZWFz ZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGF1dGhvcnMgYW5kIHRoZSBEQVJUIG1haWxpbmcg bGlzdC4gSWYgeW91J3ZlIHJldmlld2VkIGl0IGFuZCB0aGluayBpdCdzIGdvb2QgdG8gZ28sIHBs ZWFzZSBzYXkgc28uDQo+Pg0KPj4gVGhhbmtzIQ0KPj4NCj4+IEJlbi4NCj4+DQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gRGFydCBtYWlsaW5n IGxpc3QNCj4+IERhcnRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGFydA0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBEYXJ0IG1haWxpbmcgbGlzdA0KPj4gRGFydEBpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYXJ0DQo+PiAuDQo+Pg0KPiAN Cg0K From nobody Wed Aug 13 13:33:16 2014 Return-Path: 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 B80AC1A0462 for ; Wed, 13 Aug 2014 13:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 I793hAcZdKrk for ; Wed, 13 Aug 2014 13:33:10 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7891A007F for ; Wed, 13 Aug 2014 13:33:10 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 105232B4481; Wed, 13 Aug 2014 21:33:08 +0100 (BST) Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 110782B41E7 for ; Wed, 13 Aug 2014 21:33:07 +0100 (BST) Message-ID: <53EBCB82.9010901@erg.abdn.ac.uk> Date: Wed, 13 Aug 2014 21:33:06 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dart@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/HtvUnJtwyeJuT8gOqPBIRz5rd2k Subject: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 20:33:14 -0000 I can see good points raised on the details, instead I have some questions about the overall document strcuture: (1) This statement appears at the end of section 2: "Multiplexing may reduce the complexity and resulting load on an endpoint. A single instance of STUN/ICE/TURN is simpler to execute and manage than multiple instances STUN/ICE/TURN operations happening in parallel, as the latter require synchronization and create more complex failure situations that have to be cleaned up by additional code." I suspect this is all true, but I'd like to ask that section 4 also makes a similar summary claim at the end - saying that using a single 5 tuple and multiplexing multiple streams with *different* QoS expectation and therefore different DSCP markings can complicate the transport protocol design, by requiring a transport to disambiguate the congestion state for each network QoS category that is used. It will also result in increased complexity at the transport layer to validate path integrity, where a 5-tuple could result in a different routing/forwarding path in order to validate that the individual 5-tuples are reachable. Of course, using DSCPs with an AF class can reduce some of the latter costs. etc according to what the draft says. I don't suggest that the extra complexity and additional algorithms are as big a problem as being unable to get through a NAPT/Firewall, but it seems that this nonetheless extra stuff that I don't recall having been worked upon before in the IETF - and a challenge I guess for the RMCAT WG. (2) I don't know if the document's goal is also to make transport recommendations for using multiple code points - i.e.things such as must be robust to the network changing a DSCP; needs to independently verify that a particular DCSP is not being black-holed, needs to not imply relative precedence when interpreting loss or marking of packets for a flow using multiple DCSPs etc. ??? If these are out of scope, then maybe the document should say that this particular document does not provide this sort of guidance. Gorry From nobody Wed Aug 13 13:37:03 2014 Return-Path: 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 B8D781A067F for ; Wed, 13 Aug 2014 13:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 BLNmQHS_SQuk for ; Wed, 13 Aug 2014 13:37:01 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E189F1A024C for ; Wed, 13 Aug 2014 13:37:00 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id rd3so308347pab.40 for ; Wed, 13 Aug 2014 13:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5yuuynSYwncjkzMEHy+6Xto8OCKnCP4DKSoOCWbCxyY=; b=kIEd61d4ibdmY5nPDOHL+HV1biokru8W3ihpAnPpaOmnSjRejY9mPqg198FQM0dcMU fLHq9QIAMzlysdF/PYdzcSOEXeidiuos2VPYPnbYpeH94UeU7BnaarjkZs9htsAjnQBf cmshKmygMeD6MVhdmlf359Zp7jBen87HPXF/YOt9SJFsOaAagOZHDfcWIG30pefpt9GV dOiUAga2L4MRqjnQBN0Q93QptTyEMnkwc19Ze7vzaVnUWz1HndVIl263oH+/TlGDa7Rk hxiBPhNQmb4l8tF2jCae6Bz1H/5O0gwi3wnyEhppMAC3Htq46Jo9nYb/OQX3YLt8rYps 89zQ== X-Received: by 10.70.35.15 with SMTP id d15mr6259979pdj.48.1407962220567; Wed, 13 Aug 2014 13:37:00 -0700 (PDT) Received: from [192.168.178.23] (60.199.69.111.dynamic.snap.net.nz. [111.69.199.60]) by mx.google.com with ESMTPSA id gs2sm3016347pbc.20.2014.08.13.13.36.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Aug 2014 13:37:00 -0700 (PDT) Message-ID: <53EBCC70.6000004@gmail.com> Date: Thu, 14 Aug 2014 08:37:04 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Taht References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/GbIYQnadFpng9JvoHpXCgkGaPh4 Cc: dart@ietf.org Subject: Re: [Dart] [rtcweb] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 20:37:03 -0000 On 13/08/2014 13:43, Dave Taht wrote: ... > It is kind of hard to wrap your head around how 802.11e actually > works, but, this is a start: > > http://en.wikipedia.org/wiki/IEEE_802.11e-2005#Enhanced_distributed_channel_access_.28EDCA.29 > > In linux wifi at least: > > CS0, CS3 are mapped into the BE hw queue > CS1, CS2 are mapped into the BK hw queue > CS4, CS5 are mapped into the VI hw queue > CS6, CS7 are mapped into the VO hw queue > > Bit patterns for the other classes to whatever extent they map into > CSX are mapped into the underlying hardware queue. > > I am not saying this is an optimal state of affairs, Far from it. For example, if the host software is under the illusion that CS1 selects the LE behaviour (RFC 3662) it must be wrong to put it in the same hardware queue as CS2. It it is also a false assumption that the CSx bits map appropriately from other DSCP values - why should they? If diffserv is correctly implemented at level 3, all all packets should end up in the correct order in the output queue and hardware classes shouldn't be used at all IMHO. Brian > (as notably VO > should be as completely disabled as possible in the 802.11n and ac > age), and am very interested in how other OSes (ios, osx, windows), > and router/switch OSes do it, but the wireless scheduling aspect of > all these codepoints does not seem to be well touched upon. > > On a personal note I tend to think that having 17+ ways to slice up > traffic is about 13 or 14 too many, particularly those targetting a > drop probability. When you have drop rates well below a few percentage > points, adding another percentage point of granularity seems futile. > > Lastly, there is also an implementation issue in linux presently in > that doing extensive diffserv classification basically requires > one iptables or tc rule per class, which is inefficient. Someone (not > me!) doing some code for doing diffserv saner there would go a long > way... > From nobody Thu Aug 14 05:08:12 2014 Return-Path: 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 39F371A0AB4 for ; Thu, 14 Aug 2014 05:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.518 X-Spam-Level: X-Spam-Status: No, score=-4.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 g3d5P0t_3BWt for ; Thu, 14 Aug 2014 05:08:05 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCEED1A082C for ; Thu, 14 Aug 2014 05:08:04 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 14 Aug 2014 14:08:02 +0200 X-IronPort-AV: E=Sophos;i="5.01,862,1400018400"; d="scan'208";a="514765663" Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 14 Aug 2014 14:08:02 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 14 Aug 2014 14:08:02 +0200 From: To: Date: Thu, 14 Aug 2014 14:08:00 +0200 Thread-Topic: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 Thread-Index: Ac+3NdDg2pYqc89XTwOPmTJ9fU6ddQAgLTfQ Message-ID: References: <53EBCB82.9010901@erg.abdn.ac.uk> In-Reply-To: <53EBCB82.9010901@erg.abdn.ac.uk> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/e2KJmQFHVu-o_m0YRmcPdPJjt2M Cc: dart@ietf.org Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 12:08:08 -0000 Hi Gorry, the following text will likely appear in the next version of my diffserv-in= tercon draft. The more DSCPs appear in a flow which aren't deployed end-to-= end for the corresponding PHB, the more often one of the scenarios will be = encountered. The following scenarios start from a domain sending=20 IP traffic using a PHB and a corresponding DSCP to an interconnected=20 domain. The receiving domain may - Support the PHB and offer the same corresponding DSCP - Not support the PHB and use the DSCP for a different PHB - Not support the PHB and not use the DSCP - Support the PHB with a differing DSCP, and the DSCP of the sending domain is not used for another PHB - Support the PHB with a differing DSCP, and the DSCP of the sending domain is used for another PHB Another question to be answered then is how a network provider will treat u= nrecognized or unexpected DSCPs received at network boundaries. Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Gorry Fairhurst Gesendet: Mittwoch, 13. August 2014 22:33 An: dart@ietf.org Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 I can see good points raised on the details, instead I have some questions = about the overall document strcuture: [snip] (2) I don't know if the document's goal is also to make transport recommend= ations for using multiple code points - i.e.things such as must be robust t= o the network changing a DSCP; needs to independently verify that a particu= lar DCSP is not being black-holed, needs to not imply relative precedence w= hen interpreting loss or marking of packets for a flow using multiple DCSPs= etc. ??? If these are out of scope, then maybe the document should say that this par= ticular document does not provide this sort of guidance. Gorry _______________________________________________ Dart mailing list Dart@ietf.org https://www.ietf.org/mailman/listinfo/dart From nobody Thu Aug 14 06:06:39 2014 Return-Path: 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 4F6371A06EE for ; Thu, 14 Aug 2014 06:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 U2nk8iYw4UIt for ; Thu, 14 Aug 2014 06:06:27 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7E40E1A0AF1 for ; Thu, 14 Aug 2014 06:05:39 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 9455A2B436A; Thu, 14 Aug 2014 14:05:35 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 14 Aug 2014 14:05:36 +0100 Message-ID: <7dbc0254bcbb80771a8e36d2cc255512.squirrel@www.erg.abdn.ac.uk> In-Reply-To: References: <53EBCB82.9010901@erg.abdn.ac.uk> Date: Thu, 14 Aug 2014 14:05:36 +0100 From: gorry@erg.abdn.ac.uk To: Ruediger.Geib@telekom.de User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Smp4ExR0fwvJkNJrk-g-oy-3j0s Cc: gorry@erg.abdn.ac.uk, dart@ietf.org Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 13:06:30 -0000 Thanks When I said "transport" I was thinking of the algorithms to be used in the end-host to figure out what was operational and where congestion and delay were experienced. But what you say is all an import part. I expect what you discuss, could go into the tsvwg intercom draft. Gorry > Hi Gorry, > > the following text will likely appear in the next version of my > diffserv-intercon draft. The more DSCPs appear in a flow which aren't > deployed end-to-end for the corresponding PHB, the more often one of the > scenarios will be encountered. > > The following scenarios start from a domain sending > IP traffic using a PHB and a corresponding DSCP to an interconnected > domain. The receiving domain may > - Support the PHB and offer the same corresponding DSCP > - Not support the PHB and use the DSCP for a different PHB > - Not support the PHB and not use the DSCP > - Support the PHB with a differing DSCP, and the DSCP of the > sending domain is not used for another PHB > - Support the PHB with a differing DSCP, and the DSCP of the > sending domain is used for another PHB > > Another question to be answered then is how a network provider will treat > unrecognized or unexpected DSCPs received at network boundaries. > > Regards, > > Ruediger > > > -----Ursprngliche Nachricht----- > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Gorry Fairhurst > Gesendet: Mittwoch, 13. August 2014 22:33 > An: dart@ietf.org > Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 > > > I can see good points raised on the details, instead I have some questions > about the overall document strcuture: > > [snip] > > (2) I don't know if the document's goal is also to make transport > recommendations for using multiple code points - i.e.things such as must > be robust to the network changing a DSCP; needs to independently verify > that a particular DCSP is not being black-holed, needs to not imply > relative precedence when interpreting loss or marking of packets for a > flow using multiple DCSPs etc. ??? > > If these are out of scope, then maybe the document should say that this > particular document does not provide this sort of guidance. > > Gorry > > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart > From nobody Thu Aug 14 06:16:13 2014 Return-Path: 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 4941C1A0438 for ; Thu, 14 Aug 2014 06:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 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_LOW=-0.7, 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 lUdGFYAVpte6 for ; Thu, 14 Aug 2014 06:16:08 -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 A2D311A06EA for ; Thu, 14 Aug 2014 06:16:07 -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 s7EDG4dj026946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2014 09:16:05 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s7EDG4dj026946 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408022165; bh=fE2+BB8bY6tqL4U4fnIogyMYssI=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=WRDeKHNsz2q8FM1SXxQ3FCp4hI0Jt5CVhNa8cNBWVPTHpJ+M5EM4Avv2DZldGZk4D 0gVE/qPXnmraIOIRbyDyS3ejEjGoxfi70lVC/cnpr3bpcs8dUPfgI9MuOWRyn/onpa tIVRQ9BI0E2oUtnY/z6rEqImSdCamnu1mFuRq/UM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s7EDG4dj026946 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd06.lss.emc.com (RSA Interceptor); Thu, 14 Aug 2014 06:15:52 -0700 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7EDFocF029184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Aug 2014 09:15:51 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Thu, 14 Aug 2014 09:15:51 -0400 From: "Black, David" To: "gorry@erg.abdn.ac.uk" , "Ruediger.Geib@telekom.de" Date: Thu, 14 Aug 2014 09:15:49 -0400 Thread-Topic: WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2) Thread-Index: Ac+3wdu20KNcvqj8Tw+IHKeL3fYW+w== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077B951FF0@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: DLM_1, public, GIS Solicitation Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Worq08EdX7nLrOeKeT_gd1lsUJY Cc: "Black, David" , "dart@ietf.org" Subject: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 13:16:11 -0000 Wearing none of my hats, I would prefer to put Gorry's item (2) into a TSV (Transport Area) draft somewhere, and hence prefer the suggestion to say that this document does not provide that sort of guidance. > > (2) I don't know if the document's goal is also to make transport > > recommendations for using multiple code points - i.e., things such as m= ust > > be robust to the network changing a DSCP; needs to independently verify > > that a particular DCSP is not being black-holed, needs to not imply > > relative precedence when interpreting loss or marking of packets for a > > flow using multiple DCSPs etc. ??? > > > > If these are out of scope, then maybe the document should say that this > > particular document does not provide this sort of guidance. Thanks, --David > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of gorry@erg.abdn.ac.= uk > Sent: Thursday, August 14, 2014 9:06 AM > To: Ruediger.Geib@telekom.de > Cc: gorry@erg.abdn.ac.uk; dart@ietf.org > Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >=20 > Thanks >=20 > When I said "transport" I was thinking of the algorithms to be used in th= e > end-host to figure out what was operational and where congestion and dela= y > were experienced. But what you say is all an import part. I expect what > you discuss, could go into the tsvwg intercom draft. >=20 >=20 > Gorry > > Hi Gorry, > > > > the following text will likely appear in the next version of my > > diffserv-intercon draft. The more DSCPs appear in a flow which aren't > > deployed end-to-end for the corresponding PHB, the more often one of th= e > > scenarios will be encountered. > > > > The following scenarios start from a domain sending > > IP traffic using a PHB and a corresponding DSCP to an interconnected > > domain. The receiving domain may > > - Support the PHB and offer the same corresponding DSCP > > - Not support the PHB and use the DSCP for a different PHB > > - Not support the PHB and not use the DSCP > > - Support the PHB with a differing DSCP, and the DSCP of the > > sending domain is not used for another PHB > > - Support the PHB with a differing DSCP, and the DSCP of the > > sending domain is used for another PHB > > > > Another question to be answered then is how a network provider will tre= at > > unrecognized or unexpected DSCPs received at network boundaries. > > > > Regards, > > > > Ruediger > > > > > > -----Urspr=FCngliche Nachricht----- > > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Gorry Fairhurst > > Gesendet: Mittwoch, 13. August 2014 22:33 > > An: dart@ietf.org > > Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 > > > > > > I can see good points raised on the details, instead I have some questi= ons > > about the overall document strcuture: > > > > [snip] > > > > (2) I don't know if the document's goal is also to make transport > > recommendations for using multiple code points - i.e.things such as mus= t > > be robust to the network changing a DSCP; needs to independently verify > > that a particular DCSP is not being black-holed, needs to not imply > > relative precedence when interpreting loss or marking of packets for a > > flow using multiple DCSPs etc. ??? > > > > If these are out of scope, then maybe the document should say that this > > particular document does not provide this sort of guidance. > > > > Gorry > > > > _______________________________________________ > > Dart mailing list > > Dart@ietf.org > > https://www.ietf.org/mailman/listinfo/dart > > >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Thu Aug 14 06:33:44 2014 Return-Path: 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 55E2A1A0056 for ; Thu, 14 Aug 2014 06:33:43 -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 8F_ejBjRI3DX for ; Thu, 14 Aug 2014 06:33:41 -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 237271A0343 for ; Thu, 14 Aug 2014 06:33:40 -0700 (PDT) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7EDXaB1026791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2014 09:33:38 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s7EDXaB1026791 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408023218; bh=djs1FJodXed4GnzwhouBGtCyORw=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=AIpECygMdbfLs5Cj5X507+RMwDN1NGU/Yhqd/nMpRJXu+UN7INPhSFsZQUFHqzWt5 aiA6fNPgyUdZr0evsfNT7ErQCWRA57JQqfIC9OUfJw9EhXC00T1J6kuxwMaVtRNNaZ raXcrDnSAlp0ROGpca6d8a+bwOsppRZDzwJA+3ZE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s7EDXaB1026791 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd54.lss.emc.com (RSA Interceptor); Thu, 14 Aug 2014 09:33:30 -0400 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7EDXUWd019721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Aug 2014 09:33:30 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Thu, 14 Aug 2014 09:33:30 -0400 From: "Black, David" To: "gorry@erg.abdn.ac.uk" , "dart@ietf.org" Date: Thu, 14 Aug 2014 09:33:28 -0400 Thread-Topic: WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (1) Thread-Index: Ac+3xFUD6VuA6NTbTjaBZe5E13BHWw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077B95200D@MX15A.corp.emc.com> 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: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Eo_YswzBEEmKtiQvDE2-6Qr6pZs Cc: "Black, David" Subject: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (1) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 13:33:43 -0000 Gorry Fairhurst commented: > (1) This statement appears at the end of section 2: >=20 > "Multiplexing may reduce the complexity and resulting load on an > endpoint. A single instance of STUN/ICE/TURN is simpler to execute > and manage than multiple instances STUN/ICE/TURN operations happening > in parallel, as the latter require synchronization and create more > complex failure situations that have to be cleaned up by additional > code." >=20 >=20 > I suspect this is all true, but I'd like to ask that section 4 also > makes a similar summary claim at the end - saying that using a single 5 > tuple and multiplexing multiple streams with *different* QoS expectation > and therefore different DSCP markings can complicate the transport > protocol design, by requiring a transport to disambiguate the congestion > state for each network QoS category that is used. It will also result in > increased complexity at the transport layer to validate path integrity, > where a 5-tuple could result in a different routing/forwarding path in > order to validate that the individual 5-tuples are reachable. Of > course, using DSCPs with an AF class can reduce some of the latter > costs. etc. according to what the draft says. The draft's been reorganized since the version that Gorry reviewed, so the guidelines that were in Section 4 are now in Section 6. This does feel like a good discussion to add, as it strengthens the rationa= le for a single PHB/DSCP for a single TCP connection, SCTP association or DCCP connection. This discussion feels like it belongs in Section 5 somewhere, and I would say the same for some of the rationale for that single PHB/DSCP guideline, as it's not as clear as it could be about reordering (always a b= ad idea) and different drop precedences (complexity, lack of operational experience), and hence could use some elaboration. I'd suggest a new Section 5.4 on "single PHB/DSCP for a single TCP connecti= on, SCTP association or DCCP connection" to expand that rationale and pick up discussion of Gorry's item (1), as it applies (in different ways) to both reordering and different drop precedences. That would be accompanied by a rewrite of the single PHB/DSCP guideline bullet.=20 I'll try to work on some text offline w/Gorry with the goal of posting it to the list sometime next week. Thanks, --David > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Gorry Fairhurst > Sent: Wednesday, August 13, 2014 4:33 PM > To: dart@ietf.org > Subject: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >=20 >=20 > I can see good points raised on the details, instead I have some > questions about the overall document strcuture: >=20 > (1) This statement appears at the end of section 2: >=20 > "Multiplexing may reduce the complexity and resulting load on an > endpoint. A single instance of STUN/ICE/TURN is simpler to execute > and manage than multiple instances STUN/ICE/TURN operations happening > in parallel, as the latter require synchronization and create more > complex failure situations that have to be cleaned up by additional > code." >=20 >=20 > I suspect this is all true, but I'd like to ask that section 4 also > makes a similar summary claim at the end - saying that using a single 5 > tuple and multiplexing multiple streams with *different* QoS expectation > and therefore different DSCP markings can complicate the transport > protocol design, by requiring a transport to disambiguate the congestion > state for each network QoS category that is used. It will also result in > increased complexity at the transport layer to validate path integrity, > where a 5-tuple could result in a different routing/forwarding path in > order to validate that the individual 5-tuples are reachable. Of > course, using DSCPs with an AF class can reduce some of the latter > costs. etc according to what the draft says. >=20 > I don't suggest that the extra complexity and additional algorithms are > as big a problem as being unable to get through a NAPT/Firewall, but it > seems that this nonetheless extra stuff that I don't recall having been > worked upon before in the IETF - and a challenge I guess for the RMCAT WG= . >=20 > (2) I don't know if the document's goal is also to make transport > recommendations for using multiple code points - i.e.things such as > must be robust to the network changing a DSCP; needs to independently > verify that a particular DCSP is not being black-holed, needs to not > imply relative precedence when interpreting loss or marking of packets > for a flow using multiple DCSPs etc. ??? >=20 > If these are out of scope, then maybe the document should say that this > particular document does not provide this sort of guidance. >=20 > Gorry >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Thu Aug 14 12:58:12 2014 Return-Path: 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 8ABB31A872A for ; Thu, 14 Aug 2014 12:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 pIT5RnYhRtbb for ; Thu, 14 Aug 2014 12:58:08 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FDD1A871D for ; Thu, 14 Aug 2014 12:58:08 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kx10so2208010pab.20 for ; Thu, 14 Aug 2014 12:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yn8UjWE0RJs1lNRpYuBwrjwBZ0a+MQKCMzIhq18wkJ8=; b=PcDB5ttYXBpqbPyNlYYL1TXWx9y3iwtkD/tetDgSvPb6odat/fdzhBTcVnjbl0GAkj JUf/UhaEdTGnjTurcNJlgDHoHvib7k0m7Wqyovj6tZ7CDg5gliK7mi6/9dQ/NGJYr0FS 0TGqbBYYpoG4NBggMr885nrsSWOSsMwC0jZlSl4dVXbGwjG4Vy9trASUWP5FBb868lNZ TXb8ZuOAR9vTV/Yqvwnu2KfDAbSj3dBM0xb9P+GhA3neqEEZZlrGZgSfoP5LSLzcpvZ9 2rBuVDl8bCKwBGqAHPbR4P7VC4DTVE7tvoDwuTA7uqN4Ju1MhrTI7S/VXPlo14l58fR6 UFDg== X-Received: by 10.68.231.138 with SMTP id tg10mr6536552pbc.72.1408046287728; Thu, 14 Aug 2014 12:58:07 -0700 (PDT) Received: from [192.168.178.23] (254.198.69.111.dynamic.snap.net.nz. [111.69.198.254]) by mx.google.com with ESMTPSA id dw8sm20396626pab.35.2014.08.14.12.58.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Aug 2014 12:58:07 -0700 (PDT) Message-ID: <53ED14D0.7000206@gmail.com> Date: Fri, 15 Aug 2014 07:58:08 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <53EBCB82.9010901@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/DhXF_POJl6SBP0dh8kmGReIU64w Cc: gorry@erg.abdn.ac.uk, dart@ietf.org Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 19:58:09 -0000 > Another question to be answered then is how a network provider will treat unrecognized or unexpected DSCPs received at network boundaries. Quoting RFC 2475: "A DS domain has a well-defined boundary consisting of DS boundary nodes which classify and possibly condition ingress traffic to ensure that packets which transit the domain are appropriately marked to select a PHB from one of the PHB groups supported within the domain." In other words the assumption is that (unless there's an SLA that allows the receiving domain to trust the incoming DSCP), a classifier is needed. My assumption has always been that the default classifier will simply re-mark packets with the default DSCP. We also have "A DS ingress node is responsible for ensuring that the traffic entering the DS domain conforms to any TCA between it and the other domain to which the ingress node is connected." and the definition of a TCA: " Traffic Conditioning an agreement specifying classifier rules Agreement (TCA) and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply to the traffic streams selected by the classifier. A TCA encompasses all of the traffic conditioning rules explicitly specified within a SLA along with all of the rules implicit from the relevant service requirements and/or from a DS domain's service provisioning policy." In other words: the treatment of unrecognized DSCPs needs to be stated in the TCA part of the SLA. Of course you could suggest a default approach in diffserv-intercon. Brian From nobody Thu Aug 14 22:08:42 2014 Return-Path: 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 8C4DA1A89F5 for ; Thu, 14 Aug 2014 22:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.518 X-Spam-Level: X-Spam-Status: No, score=-4.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 zY-FF7C6eGGO for ; Thu, 14 Aug 2014 22:08:36 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98841A00C5 for ; Thu, 14 Aug 2014 22:08:34 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 15 Aug 2014 07:08:32 +0200 X-IronPort-AV: E=Sophos;i="5.01,867,1400018400"; d="scan'208";a="515090698" Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 15 Aug 2014 07:08:32 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Fri, 15 Aug 2014 07:08:32 +0200 From: To: Date: Fri, 15 Aug 2014 07:08:31 +0200 Thread-Topic: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 Thread-Index: Ac+3+hUjwVARCRWoSjKWP4eFVivXEgAS3JsA Message-ID: References: <53EBCB82.9010901@erg.abdn.ac.uk> <53ED14D0.7000206@gmail.com> In-Reply-To: <53ED14D0.7000206@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/4BgUspC3FJmKyf5ne1pavl9u0qo Cc: dart@ietf.org Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 05:08:40 -0000 Hi Brian, standards agree on the PHB which unrecognised DSCPs should receive, which i= s=20 default forwarding. RFC2474 however proposes to transport the DSCP without= =20 remarking:=20 Packets received with an unrecognized codepoint SHOULD be forwarded as if they were marked for the Default behavior (see Sec. 4), and their codepoints should not be changed. Such packets MUST NOT cause the network node to malfunction. The MUST NOT cause malfunction clause leaves a way out and I personally=20 favor rewrite to default DSCP. There has been a discussion whether a rewrite of several incoming DSCP=20 to a single outgoing DSCP is DiffServ compatible or not. Here we have=20 such a rewrite. It seems to be alright for not supported DSCPs and PHBs. As you mention, a TCA/SLA stating treatment of all DSCPs is important=20 at network domain boundaries. Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Brian E Carpenter Gesendet: Donnerstag, 14. August 2014 21:58 An: Geib, R=FCdiger Cc: gorry@erg.abdn.ac.uk; dart@ietf.org Betreff: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 > Another question to be answered then is how a network provider will treat= unrecognized or unexpected DSCPs received at network boundaries. Quoting RFC 2475: "A DS domain has a well-defined boundary consisting of DS boundary nodes which classify and possibly condition ingress traffic to ensure that packets which transit the domain are appropriately marked to select a PHB from one of the PHB groups supported within the domain." In other words the assumption is that (unless there's an SLA that allows th= e receiving domain to trust the incoming DSCP), a classifier is needed. My = assumption has always been that the default classifier will simply re-mark = packets with the default DSCP. We also have "A DS ingress node is responsible for ensuring that the traffic entering the DS domain conforms to any TCA between it and the other domain to which the ingress node is connected." and the definition of a TCA: " Traffic Conditioning an agreement specifying classifier rules Agreement (TCA) and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply to the traffic streams selected by the classifier. A TCA encompasses all of the traffic conditioning rules explicitly specified within a SLA along with all of the rules implicit from the relevant service requirements and/or from a DS domain's service provisioning policy." In other words: the treatment of unrecognized DSCPs needs to be stated in t= he TCA part of the SLA. Of course you could suggest a default approach in diffserv-intercon. Brian _______________________________________________ Dart mailing list Dart@ietf.org https://www.ietf.org/mailman/listinfo/dart From nobody Mon Aug 18 08:20:08 2014 Return-Path: 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 35FE21A04B0; Mon, 18 Aug 2014 08:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qp90o-vq4DyF; Mon, 18 Aug 2014 08:17:49 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3349D1A0564; Mon, 18 Aug 2014 08:17:49 -0700 (PDT) Received: from [130.209.247.112] (port=53852 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XJOgs-0000mM-PF; Mon, 18 Aug 2014 16:17:47 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> Date: Mon, 18 Aug 2014 16:17:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3E113BE1-6DD3-4473-8C46-9507EABD6472@csperkins.org> References: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> To: dart@ietf.org X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/2GoElL1i7wOOkHjm-jtAOsJ1P-Q X-Mailman-Approved-At: Mon, 18 Aug 2014 08:20:04 -0700 Cc: Ben Campbell , "avt@ietf.org WG" , draft-ietf-dart-dscp-rtp.all@tools.ietf.org Subject: Re: [Dart] [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 15:17:51 -0000 Hi, [I=92m 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.=20 The four bullet points in Section 2.1 that follow =93The RTCWEB protocol = suit encompasses a number of forms of multiplexing=94 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=20= > together in a number of ways: >=20 > 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; >=20 > 2. The RTP Control Protocol (RTCP) [RFC3550] may be multiplexed = onto > the same transport-layer flow as the RTP stream with which it = is=20 > associated, as described in [RFC5761], or it may be sent on a=20= > separate transport-layer flow; >=20 > 3. The RTP and RTCP traffic can be multiplexed with other = protocols=20 > via UDP encapsulation over a common pair of UDP ports as = described=20 > in [RFC5764] as updated by > [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]; and >=20 > 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 =93unidirectional UDP packet flow=94 to = =93transport-layer flow=94 since it will not be unidirectional (since = RTCP also flows in the reverse direction), and might not use UDP.=20 In the first paragraph of section 2.2, I suggest changing =93multiplexed = over RTP sessions=94 to =93multiplexed in a single RTP session=94 and = =93multiplexing of source streams in RTP sessions=94 to =93multiplexing = of source streams in a single RTP session=94.=20 In Section 6, the second bullet point refers to =93an RTCP session=94. = 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=92s 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 =93RTCWEB=94 in this draft = need to change to =93WebRTC=94. Cheers, Colin On 9 Aug 2014, at 19:48, Ben Campbell wrote: > Hi, >=20 > 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.=20 >=20 > 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. >=20 > Thanks! >=20 > Ben. >=20 > Begin forwarded message: >=20 >> Resent-From: draft-alias-bounces@tools.ietf.org >> From: Ben Campbell >> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 >> Date: August 9, 2014 at 12:50:16 PM CDT >> Resent-To: ben@nostrum.com, david.black@emc.com, = paulej@packetizer.com >> To: dart@ietf.org >> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com, = Richard Barnes >>=20 >> 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: >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >>=20 >> 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. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From nobody Mon Aug 18 13:48:39 2014 Return-Path: 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 5A0A11A6F97; Mon, 18 Aug 2014 13:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 3ONWg2xalgkC; Mon, 18 Aug 2014 13:48:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586101A0171; Mon, 18 Aug 2014 13:48:33 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7IKmQhS008709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Aug 2014 15:48:27 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <3E113BE1-6DD3-4473-8C46-9507EABD6472@csperkins.org> Date: Mon, 18 Aug 2014 15:48:25 -0500 X-Mao-Original-Outgoing-Id: 430087705.672792-c8dfb1c8192db3c7b3a0a57ecfafb23e Content-Transfer-Encoding: quoted-printable Message-Id: References: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> <3E113BE1-6DD3-4473-8C46-9507EABD6472@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/fxQ769pjece9KuoTee48Vsib-PY Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, dart@ietf.org, "avt@ietf.org WG" Subject: Re: [Dart] [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 20:48:35 -0000 Hi, I concur with all of Colin's comments, save one question below: On Aug 18, 2014, at 10:17 AM, Colin Perkins wrote: > Hi, >=20 > [I=92m not on the DART list, so please cc me in replies] >=20 > This draft looks good overall, but I did have some comments, primarily = about the discussion of RTP multiplexing.=20 >=20 > The four bullet points in Section 2.1 that follow =93The RTCWEB = protocol suit encompasses a number of forms of multiplexing=94 seem to = confuse RTP sessions, > RTCP, and transport-layer flows. I suggest they be changed to: >=20 >> The RTP streams that comprise a WebRTC session can be multiplexed=20= >> together in a number of ways: >>=20 >> 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; >>=20 >> 2. The RTP Control Protocol (RTCP) [RFC3550] may be multiplexed = onto >> the same transport-layer flow as the RTP stream with which it = is=20 >> associated, as described in [RFC5761], or it may be sent on a=20= >> separate transport-layer flow; >>=20 >> 3. The RTP and RTCP traffic can be multiplexed with other = protocols=20 >> via UDP encapsulation over a common pair of UDP ports as = described=20 >> in [RFC5764] as updated by >> [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]; and Can we clarify what "other protocols" are expected? Are we just talking = about WebRTC data-channels over SCTP/DTLS, or other things? If the = latter, are we talking things we expect to do today, or in immediate = futures, or extensions that might happen someday? >>=20 >> 4. The data may be further encapsulated via STUN [RFC5389] and = TURN >> [RFC5766] for NAT (Network Address Translator) traversal. >=20 > In the following paragraph (penultimate paragraph in Section 2.1), I = suggest changing =93unidirectional UDP packet flow=94 to = =93transport-layer flow=94 since it will not be unidirectional (since = RTCP also flows in the reverse direction), and might not use UDP.=20 >=20 > In the first paragraph of section 2.2, I suggest changing =93multiplexed= over RTP sessions=94 to =93multiplexed in a single RTP session=94 and = =93multiplexing of source streams in RTP sessions=94 to =93multiplexing = of source streams in a single RTP session=94.=20 >=20 > In Section 6, the second bullet point refers to =93an RTCP session=94. = 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=92s 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. >=20 > Editorial: the protocol is called WebRTC, but the working group is = RTCWEB. Accordingly, I think all instances of =93RTCWEB=94 in this draft = need to change to =93WebRTC=94. >=20 > Cheers, > Colin >=20 >=20 >=20 >=20 >=20 > On 9 Aug 2014, at 19:48, Ben Campbell wrote: >> Hi, >>=20 >> 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.=20 >>=20 >> 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. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> Begin forwarded message: >>=20 >>> Resent-From: draft-alias-bounces@tools.ietf.org >>> From: Ben Campbell >>> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 >>> Date: August 9, 2014 at 12:50:16 PM CDT >>> Resent-To: ben@nostrum.com, david.black@emc.com, = paulej@packetizer.com >>> To: dart@ietf.org >>> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com, = Richard Barnes >>>=20 >>> 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: >>>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >>>=20 >>> 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. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>=20 >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 From nobody Mon Aug 18 14:49:35 2014 Return-Path: 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 61EBB1A7018 for ; Mon, 18 Aug 2014 14:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 NSmMrBeW9ePI for ; Mon, 18 Aug 2014 14:49:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B661F1A0020 for ; Mon, 18 Aug 2014 14:49:30 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7ILnRvQ024002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Aug 2014 16:49:29 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell Date: Mon, 18 Aug 2014 16:49:27 -0500 X-Mao-Original-Outgoing-Id: 430091367.393255-ed1b2af09bffb257f26a65032f94c2f2 Content-Transfer-Encoding: quoted-printable Message-Id: <62D70F5C-C6CF-48C7-AE9F-55B17172555D@nostrum.com> To: draft-ietf-dart-dscp-rtp.all@tools.ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/u1FWMEiB2rf6iZRxfAY-ihiDROc Cc: dart@ietf.org Subject: [Dart] WGLC Comments on draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 21:49:32 -0000 (As individual) Hi, Here are some WGLC comments on draft-ietf-dart-dscp-rtp-02. Thanks! Ben. ---------------- **** Substantive: -- General:=20 I was going to ask if we can be more precise on what sort of layering = (and muxing?) we expect to really happen on top of DTLS, especially for = WebRTC use cases. But I think Colin's comments are on the right track, = so I will comment in that thread. -- Abstract (and intro) It's probably worth mentioning that, other than mixing RTP/RTCP, RTP = multiplexing is a relatively new thing. It's needed by new work such as = WebRTC and clue, and it is enabled by bundle. The point being, this = wasn't something we really needed to worry about until now. -- Section 2.1, list item 3: "An RTP session could be multiplexed with = other protocols ... " What is likely to really happen here? I don't think we will see an = arbitrary mixing of other protocols in the immediate future. What are = the realistic constraints, and likely layerings? For example, with = WebRTC, we are likely to see some number of RTP/RTCP streams, stun, = turn, and dtls, with dtls carrying one or more SCTP associations (i.e. = data channels) right? Do we have ways to signal more than that in = sdp-bundle? OTOH, I guess one could argue that people might try to mix in more = things in the future. -- 2.1, 2nd to last paragraph, last sentence (starting with "In = contrast..." Is this specific to SCTP associations carried over DTLS packets a la = RFC5764, or are we talking about SCTP/UDP in general? -- 2.2, third paragraph: Are we talking about TCP as the outer transport protocol, and muxing = things on the TCP 5-tuple? Or are we considering TCP as something that = might get multiplexed on the UDP 5-tuple? Where do Jonathan Lennox's = comments about potentially falling back to an ICE TCP candidate fit? -- section 3, paragraph 5: Does the term "network node" include application endpoints that might do = initial DiffServ marking? -- section 3, paragraph 12: "... observable forwarding behavior (e.g., = loss, delay, jitter) will often depend only on the relative loading of = the link" Relative to what? Other links? Relative load to the capacity of the = link? -- section 4: It might be nice to have a more WebRTC-ish example. For example an audio = stream, video stream, and a data channel carrying something like a = shared white board or game. -- section 6, last bullet: Is there a such thing as "less than best effort traffic" where "best = effort" treatments would be unacceptable? Actually, it's not clear to me from this paragraph if CS1 is ever = appropriate, at least from the application endpoint perspective, as it = seem to give completely unpredictable results. -- Normative References: Are these first two references both "normative" enough to block on them? **** Editorial: -- section 1, paragraph 1: "As a result use of different DSCPs..." Missing comma after "result". -- 3.2, paragraph 1: "... and such nodes remark traffic ..." May remark? Always remark? -- 3.2, paragraph 3, last sentence: Is this sentence redundant to the previous paragraph? -- 4, paragraph 1: 2nd and 3rd sentence These sentences seem to contradict. The first says that receiving audio = early is not useful, but the second says it may be useful. -- 4, 2nd paragraph: "... e.g., are in an AF class ..." in the _same_ AF class? -- 5.1, 7th paragraph Is this paragraph redundant with previous discussions of AF classes? -- 5.2, third paragraph: Can you elaborate on what it means to be "contained in a buffer"? -- 5.2, around paragraph 5: There are words about why non-interactive media is likely to have larger = jitter buffers, but the fact that interactive media may have smaller = buffers us left to implication. -- 5.3, 1st and 2nd sentence: These seem redundant to previous discussions about AF classes. -- 5.3, 2nd paragraph: It's not clear to me what this paragraph means. Is drop likelihood the = likelihood that anything is dropped in a session, or the chance of any = given packet being dropped? I assume drop likelihood is relative to that = of other sessions crossing the same path? And that under non congested = conditions none of this will matter? -- 6, 1st paragraph: " ... the following requirements ..." Are these requirements per se, or guidelines? -- 6, bullet list Each bullet starts with a verb, but ommits the subject. E.g., in the = first bullet, what is the actor that should not use different DSCPs = within a different stream? -- 6, 1st bullet: The double negation is confusing ("should not use", "If this is not = done..."). Also, 2nd bullet: Is "use a single PHB and DSCP" different than just saying "use a single = DSCP"? 3rd bullet:=20 Am I correct in assuming SCTP multihoming is not an issue here? Should = we mention that explicitly? =20= From nobody Thu Aug 21 18:06:44 2014 Return-Path: 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 54EDC1A8750; Thu, 21 Aug 2014 18:06:41 -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 vZXVwBrQrENy; Thu, 21 Aug 2014 18:06:37 -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 657CC1A875D; Thu, 21 Aug 2014 18:06:35 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7M16PgY030208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2014 21:06:26 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7M16PgY030208 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408669586; bh=Disu6cMSI9TFCBZIAWZ82n6fxOs=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=bWG/e1XBGk+coo858wGhPr8QaVD2e2Sd5gp50ozfkaC6aGzQYi5e2BGnu7wx/Us96 gt+EVqjZil4ZFf4m+kgkvOnYWl8KLfKLw9xZ68O9g2cSXZ6g6+oE+AmR+T6ywpbBro q4tSyGXbjLNr6vu7Tfxu5smkxKEWVFj8CvrdNJXs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7M16PgY030208 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd06.lss.emc.com (RSA Interceptor); Thu, 21 Aug 2014 21:06:12 -0400 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7M16GqV012510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Aug 2014 21:06:16 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub33.corp.emc.com ([::1]) with mapi; Thu, 21 Aug 2014 21:06:16 -0400 From: "Black, David" To: Ben Campbell , Colin Perkins Date: Thu, 21 Aug 2014 21:06:14 -0400 Thread-Topic: [Dart] [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 Thread-Index: Ac+7JfSVp64hNJGjTlKd7hFJVjR6pwCfmqOw Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42962@MX15A.corp.emc.com> References: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> <3E113BE1-6DD3-4473-8C46-9507EABD6472@csperkins.org> In-Reply-To: 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: mailusrhubprd51.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/0GkY-7bka7jdqDcnNZ5ua3H00d4 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [Dart] [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 01:06:41 -0000 Colin - many thanks for the review. I'll pick up your proposed changes, pe= rhaps with minor edits. Ben, > >> 3. The RTP and RTCP traffic can be multiplexed with other protocols > >> via UDP encapsulation over a common pair of UDP ports as describ= ed > >> in [RFC5764] as updated by > >> [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]; and >=20 > Can we clarify what "other protocols" are expected? Are we just talking a= bout > WebRTC data-channels over SCTP/DTLS, or other things? If the latter, are = we > talking things we expect to do today, or in immediate futures, or extensi= ons > that might happen someday? WebRTC will only multiplex its data channels, and this numbered list is abo= ut WebRTC, so this text should focus on those data channels - I'll revise the = draft accordingly. Other text elsewhere in the draft is broader (e.g., SCTP/UDP without DTLS, = which is of interest, even though WebRTC always uses DTLS). Thanks, --David > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Monday, August 18, 2014 4:48 PM > To: Colin Perkins > Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org; dart@ietf.org; avt@ietf.= org > WG > Subject: Re: [Dart] [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 >=20 > Hi, >=20 > I concur with all of Colin's comments, save one question below: >=20 > On Aug 18, 2014, at 10:17 AM, Colin Perkins wrote: >=20 > > 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 sessio= ns, > > RTCP, and transport-layer flows. I suggest they be changed to: > >=20 > >> 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 b= e > >> multiplexed onto a single transport-layer flow, forming a single > >> RTP session; > >> > >> 2. The RTP Control Protocol (RTCP) [RFC3550] may be multiplexed ont= o > >> 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 describ= ed > >> in [RFC5764] as updated by > >> [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]; and >=20 > Can we clarify what "other protocols" are expected? Are we just talking a= bout > WebRTC data-channels over SCTP/DTLS, or other things? If the latter, are = we > talking things we expect to do today, or in immediate futures, or extensi= ons > that might happen someday? >=20 > >> > >> 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 su= ggest > changing "unidirectional UDP packet flow" to "transport-layer flow" since= it > will not be unidirectional (since RTCP also flows in the reverse directio= n), > 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 s= ingle > RTP session". > > > > In Section 6, the second bullet point refers to "an RTCP session". Ther= e 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 si= ngle > 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 RTCW= EB. > Accordingly, I think all instances of "RTCWEB" in this draft need to chan= ge to > "WebRTC". > > > > Cheers, > > Colin > > > > > > > > > > > > On 9 Aug 2014, at 19:48, Ben Campbell wrote: > >> Hi, > >> > >> The DART working group has started a last call for draft-ietf-dart-dsc= p- > rtp-02, ending on August 22. This informational draft describes considera= tions > 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 wo= uld > like to solicit additional reviews from participants of TSVWG, AVTCORE, > MMUSIC, CLUE, RTCWEB, and RMCAT. Please send any feedback (including feed= back > to the effect of "this is ready to progress") to the DART working group > mailing list. > >> > >> Thanks! > >> > >> Ben. > >> > >> Begin forwarded message: > >> > >>> Resent-From: draft-alias-bounces@tools.ietf.org > >>> From: Ben Campbell > >>> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 > >>> Date: August 9, 2014 at 12:50:16 PM CDT > >>> Resent-To: ben@nostrum.com, david.black@emc.com, paulej@packetizer.co= m > >>> To: dart@ietf.org > >>> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com, > Richard Barnes > >>> > >>> 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 > >> avt@ietf.org > >> https://www.ietf.org/mailman/listinfo/avt > > > > > > > > -- > > Colin Perkins > > http://csperkins.org/ > > > > > > >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Fri Aug 22 06:47:07 2014 Return-Path: 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 DFBF51A03F8 for ; Fri, 22 Aug 2014 06:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 hmzuK91jWyE1 for ; Fri, 22 Aug 2014 06:47:02 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 42A781A03E3 for ; Fri, 22 Aug 2014 06:47:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 30BC37C3EE5 for ; Fri, 22 Aug 2014 15:47:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpL7YtSynGL8 for ; Fri, 22 Aug 2014 15:46:59 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:1c79:5878:8b25:dce8] (unknown [IPv6:2001:470:de0a:27:1c79:5878:8b25:dce8]) by mork.alvestrand.no (Postfix) with ESMTPSA id 367447C3ED6 for ; Fri, 22 Aug 2014 15:46:59 +0200 (CEST) Message-ID: <53F749D1.7050407@alvestrand.no> Date: Fri, 22 Aug 2014 15:46:57 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "dart@ietf.org" Content-Type: multipart/alternative; boundary="------------000105040802050109070102" Archived-At: http://mailarchive.ietf.org/arch/msg/dart/AWXDhymTUkr7phy_RiQqx1o2BG8 Subject: [Dart] HTA's Last Call review - drart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 13:47:06 -0000 This is a multi-part message in MIME format. --------------000105040802050109070102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit * Last Call review - drat-ietf-dart-dscp-rtp-02 http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-02 Summary: This document is not ready for IETF Last Call, but close. The recommendations are reasonable and reasonably argued, but the precision and specificity of the language needs to be tightened up before publication. The below addresses some specific concerns. Section 2 nit: “communication in real-time” -> “communication in real time” nit: The complex example needs to mention that there may be non-media streams; suggest “there may be multiple media and non-media streams”. 2.1 Reference to SSRC for reference clock is wrong - “an RTP stream may contain multiple source streams that use the same reference clock (SSRC)” - this should be “clock, identified by the same CNAME”. The SSRC has to be different for each RTP stream in an RTP session. (The naming choice here is confusing….) The section needs to mention that RTP can be carried over a non-datagram protocol such as TCP, but that this document does not say more about this - just to show that its omission is deliberate, not accidental. (In fact 5.3 discusses TCP-encapsulated RTP. So it’s appropriate to mention it here.) STUN is not an encapsulation protocol, so should be omitted from the “encapsulated via STUN” sentence. TURN is. STUN packets are, however, multiplexed with the RTP packets. Agree that the UDP stream is not unidirectional. 2.2 STUN/TURN paragraph sits oddly here. It seems to belong outside the “reasons for multiplexing” flow. Perhaps move it to the beginning of the section? Again, STUN description needs tuning; STUN is used also for enabling communication without a relay server, by exchanging publicly-visible IP addresses and ports. 4. “receiving the audio packets ahead of the video is not useful” -> “is not very useful” - the next sentence gives a reason why it is somewhat useful. 5.1 Diffserv, Reordering and Transport Protocols The paragraph “Reordering also affects other forms of congestion control” is wrong. The content is OK, but the intro is not - it is the differential treatment (including drop probability) that creates problems for RMCAT, not (just) the reordering. DCCP is sensitive to differential treatment, since it does congestion control, so description of it as “problem free” is wrong. I think there are considerations coming from reordering (which affect protocols with immediate feedback, such as ACK-based protocols), and there are consdierations from diferential treatment (guessing wrong about what’s affected by a queue). The former applies to TCP; the latter applies to TCP, SCTP, DCCP, and (probably) whatever RMCAT comes to. These two should be separated. 5.2 DiffServ, reordering and real time communication The last paragraph of the section is somewhat misleading - network packet reordering done for *whatever* reason has no upper bound. If the authors think that packet reordering is more likely to be problematic with different DSCPs than with the same DSCP, that’s what they should say. The reference to RTCP multi-stream optimization seems completely wrong. The grouping into RTCP reporting groups is about receiver SSRCs that see the same set of packets, not about grouping reports about different SSRC together. (unless I’ve misunderstood something). When not using multi-stream optimization, these SSRCs send duplicate reports. 6. Guidelines The word “requirements” seems at odds with the headline “guidelines”. The word “session” is used several times without explanation - “RTCP session”, “reliable transport protoocol session”. From context, I guess “flow” or “connection” would be more appropriate. I wonder if the first requirement can be phrased in the positive? For instance: * Within a single RTP stream, should use a single PHB and DSCP, or a set of PHBs and DSCPs that do not allow reordering, for instance a single AF class. All in all, the document*'s recommendations are clear and reasonable, but the document can be improved. * * -- Surveillance is pervasive. Go Dark. --------------000105040802050109070102 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
Last Call review - drat-ietf-dart-dscp-rtp-02
http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-02


Summary: This document is not ready for IETF Last Call, but close.
The recommendations are reasonable and reasonably argued, but the precision and specificity of the language needs to be tightened up before publication.


The below addresses some specific concerns.


Section 2


nit: “communication in real-time” -> “communication in real time”
nit: The complex example needs to mention that there may be non-media streams; suggest “there may be multiple media and non-media streams”.


2.1


Reference to SSRC for reference clock is wrong - “an RTP stream may contain multiple source streams that use the same reference clock (SSRC)” - this should be “clock, identified by the same CNAME”. The SSRC has to be different for each RTP stream in an RTP session. (The naming choice here is confusing….)


The section needs to mention that RTP can be carried over a non-datagram protocol such as TCP, but that this document does not say more about this - just to show that its omission is deliberate, not accidental.
(In fact 5.3 discusses TCP-encapsulated RTP. So it’s appropriate to mention it here.)


STUN is not an encapsulation protocol, so should be omitted from the “encapsulated via STUN” sentence. TURN is. STUN packets are, however, multiplexed with the RTP packets.


Agree that the UDP stream is not unidirectional.


2.2


STUN/TURN paragraph sits oddly here. It seems to belong outside the “reasons for multiplexing” flow. Perhaps move it to the beginning of the section?
Again, STUN description needs tuning; STUN is used also for enabling communication without a relay server, by exchanging publicly-visible IP addresses and ports.


4.


“receiving the audio packets ahead of the video is not useful” -> “is not very useful” - the next sentence gives a reason why it is somewhat useful.


5.1 Diffserv, Reordering and Transport Protocols


The paragraph “Reordering also affects other forms of congestion control” is wrong. The content is OK, but the intro is not - it is the differential treatment (including drop probability) that creates problems for RMCAT, not (just) the reordering.


DCCP is sensitive to differential treatment, since it does congestion control, so description of it as “problem free” is wrong.


I think there are considerations coming from reordering (which affect protocols with immediate feedback, such as ACK-based protocols), and there are consdierations from diferential treatment (guessing wrong about what’s affected by a queue). The former applies to TCP; the latter applies to TCP, SCTP, DCCP, and (probably) whatever RMCAT comes to. These two should be separated.


5.2 DiffServ, reordering and real time communication


The last paragraph of the section is somewhat misleading - network packet reordering done for *whatever* reason has no upper bound. If the authors think that packet reordering is more likely to be problematic with different DSCPs than with the same DSCP, that’s what they should say.


The reference to RTCP multi-stream optimization seems completely wrong. The grouping into RTCP reporting groups is about receiver SSRCs that see the same set of packets, not about grouping reports about different SSRC together. (unless I’ve misunderstood something). When not using multi-stream optimization, these SSRCs send duplicate reports.


6. Guidelines


The word “requirements” seems at odds with the headline “guidelines”.


The word “session” is used several times without explanation - “RTCP session”, “reliable transport protoocol session”. From context, I guess “flow” or “connection” would be more appropriate.


I wonder if the first requirement can be phrased in the positive? For instance:


* Within a single RTP stream, should use a single PHB and DSCP, or a set of PHBs and DSCPs that do not allow reordering, for instance a single AF class.


All in all, the document's recommendations are clear and reasonable, but the document can be improved.





 






















-- 
Surveillance is pervasive. Go Dark.
--------------000105040802050109070102-- From nobody Fri Aug 22 11:57:42 2014 Return-Path: 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 707541A0722 for ; Fri, 22 Aug 2014 11:57:40 -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 WUmy9fKzFdME for ; Fri, 22 Aug 2014 11:57:37 -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 79D881A049A for ; Fri, 22 Aug 2014 11:57:37 -0700 (PDT) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MIvXHS018387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2014 14:57:34 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s7MIvXHS018387 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408733854; bh=5NXE+CdWvoh8+urT4F6y3dOOLj4=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=TyJliOpojA/Uuv2w6FUBde+Qqddi8p0QOFw3sDuCcYgMWuaOvL2tk3EiSOcAsWv3b nFVcD4oLPdBQoBTh2bxxeXsBDsxINcm6ReF4mtLUZysEAFXb50Rvu3A7btQyK7SsLU fBCs619cMncsjgFjP1/0RDvwVt8c5FQdCYQwtJw4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com s7MIvXHS018387 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd56.lss.emc.com (RSA Interceptor); Fri, 22 Aug 2014 14:57:19 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MIvMHY029574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 14:57:23 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Fri, 22 Aug 2014 14:57:22 -0400 From: "Black, David" To: "gorry@erg.abdn.ac.uk" Date: Fri, 22 Aug 2014 14:57:21 -0400 Thread-Topic: WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2) Thread-Index: Ac+3wdu20KNcvqj8Tw+IHKeL3fYW+wGcCHlA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42A58@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077B951FF0@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077B951FF0@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public, GIS Solicitation Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Ju-RE7XtBanemFnIUvvSmRndYZc Cc: "Black, David" , "dart@ietf.org" Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 18:57:40 -0000 Here's the next to last paragraph in Section 5.3: SCTP [RFC4960] differs from TCP in a number of ways, including the ability to deliver messages in an order that differs from the order in which they were sent and support for unreliable streams. However, SCTP performs congestion control and retransmission across the entire association, and not on a per-stream basis. Although there may be advantages to using multiple drop precedence across SCTP streams or within an SCTP stream that does not use reliable ordered delivery, there is no practical operational experience in doing so (e.g., the SCTP sockets API [RFC6458] does not support use of more than one DSCP for an SCTP association). As a consequence, the impacts on SCTP protocol and implementation behavior are unknown and difficult to predict. Hence a single PHB and DSCP should be used for all packets in an SCTP association, independent of the number or nature of streams in that association. Similar reasoning applies to a DCCP connection; a single PHB and DSCP should be used because the scope of congestion control is the connection and there is no operational experience with using more than one PHB or DSCP. I propose to add the following new sentence as its own paragraph: Guidance on transport protocol design and implementation to provide support for use of multiple PHBs and DSCPs in a transport connection (e.g., DCCP) or association (e.g., SCTP) is out of scope for this document. I could add examples of topics that could be addressed, but would prefer to leave that to the actual design activity. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Thursday, August 14, 2014 9:16 AM > To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de > Cc: dart@ietf.org; Black, David > Subject: WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2) >=20 > Wearing none of my hats, I would prefer to put Gorry's item (2) into a TS= V > (Transport Area) draft somewhere, and hence prefer the suggestion to say > that this document does not provide that sort of guidance. >=20 > > > (2) I don't know if the document's goal is also to make transport > > > recommendations for using multiple code points - i.e., things such as= must > > > be robust to the network changing a DSCP; needs to independently veri= fy > > > that a particular DCSP is not being black-holed, needs to not imply > > > relative precedence when interpreting loss or marking of packets for = a > > > flow using multiple DCSPs etc. ??? > > > > > > If these are out of scope, then maybe the document should say that th= is > > > particular document does not provide this sort of guidance. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of gorry@erg.abdn.a= c.uk > > Sent: Thursday, August 14, 2014 9:06 AM > > To: Ruediger.Geib@telekom.de > > Cc: gorry@erg.abdn.ac.uk; dart@ietf.org > > Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 > > > > Thanks > > > > When I said "transport" I was thinking of the algorithms to be used in = the > > end-host to figure out what was operational and where congestion and de= lay > > were experienced. But what you say is all an import part. I expect what > > you discuss, could go into the tsvwg intercom draft. > > > > > > Gorry > > > Hi Gorry, > > > > > > the following text will likely appear in the next version of my > > > diffserv-intercon draft. The more DSCPs appear in a flow which aren't > > > deployed end-to-end for the corresponding PHB, the more often one of = the > > > scenarios will be encountered. > > > > > > The following scenarios start from a domain sending > > > IP traffic using a PHB and a corresponding DSCP to an interconnected > > > domain. The receiving domain may > > > - Support the PHB and offer the same corresponding DSCP > > > - Not support the PHB and use the DSCP for a different PHB > > > - Not support the PHB and not use the DSCP > > > - Support the PHB with a differing DSCP, and the DSCP of the > > > sending domain is not used for another PHB > > > - Support the PHB with a differing DSCP, and the DSCP of the > > > sending domain is used for another PHB > > > > > > Another question to be answered then is how a network provider will t= reat > > > unrecognized or unexpected DSCPs received at network boundaries. > > > > > > Regards, > > > > > > Ruediger > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Gorry Fairhur= st > > > Gesendet: Mittwoch, 13. August 2014 22:33 > > > An: dart@ietf.org > > > Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 > > > > > > > > > I can see good points raised on the details, instead I have some ques= tions > > > about the overall document strcuture: > > > > > > [snip] > > > > > > (2) I don't know if the document's goal is also to make transport > > > recommendations for using multiple code points - i.e.things such as m= ust > > > be robust to the network changing a DSCP; needs to independently veri= fy > > > that a particular DCSP is not being black-holed, needs to not imply > > > relative precedence when interpreting loss or marking of packets for = a > > > flow using multiple DCSPs etc. ??? > > > > > > If these are out of scope, then maybe the document should say that th= is > > > particular document does not provide this sort of guidance. > > > > > > Gorry > > > > > > _______________________________________________ > > > Dart mailing list > > > Dart@ietf.org > > > https://www.ietf.org/mailman/listinfo/dart > > > > > > > _______________________________________________ > > Dart mailing list > > Dart@ietf.org > > https://www.ietf.org/mailman/listinfo/dart From nobody Fri Aug 22 12:13:08 2014 Return-Path: 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 4E6281A0491 for ; Fri, 22 Aug 2014 12:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XdJopaUDFZ41 for ; Fri, 22 Aug 2014 12:13:05 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id AC7071A04B4 for ; Fri, 22 Aug 2014 12:13:04 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5BF282B4305; Fri, 22 Aug 2014 20:13:03 +0100 (BST) Received: from 139.133.204.3 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 22 Aug 2014 20:13:03 +0100 Message-ID: In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BB42A58@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077B951FF0@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712077BB42A58@MX15A.corp.emc.com> Date: Fri, 22 Aug 2014 20:13:03 +0100 From: gorry@erg.abdn.ac.uk To: "Black, David" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/dart/-1-ex3eCsWEiKC3Hm8e56T1_xss Cc: "gorry@erg.abdn.ac.uk" , "Black, David" , "dart@ietf.org" Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:13:07 -0000 I could live with that - it would be even nicer if we actually had a document with set of recommendations to point to - but since we don't, this seems an appropriate statement. Gorry > Here's the next to last paragraph in Section 5.3: > > SCTP [RFC4960] differs from TCP in a number of ways, including the > ability to deliver messages in an order that differs from the order > in which they were sent and support for unreliable streams. However, > SCTP performs congestion control and retransmission across the entire > association, and not on a per-stream basis. Although there may be > advantages to using multiple drop precedence across SCTP streams or > within an SCTP stream that does not use reliable ordered delivery, > there is no practical operational experience in doing so (e.g., the > SCTP sockets API [RFC6458] does not support use of more than one DSCP > for an SCTP association). As a consequence, the impacts on SCTP > protocol and implementation behavior are unknown and difficult to > predict. Hence a single PHB and DSCP should be used for all packets > in an SCTP association, independent of the number or nature of > streams in that association. Similar reasoning applies to a DCCP > connection; a single PHB and DSCP should be used because the scope of > congestion control is the connection and there is no operational > experience with using more than one PHB or DSCP. > > I propose to add the following new sentence as its own paragraph: > > Guidance on transport protocol design and implementation to provide > support for use of multiple PHBs and DSCPs in a transport connection > (e.g., DCCP) or association (e.g., SCTP) is out of scope for this > document. > > I could add examples of topics that could be addressed, but would prefer > to leave that to the actual design activity. > > Thanks, > --David > > >> -----Original Message----- >> From: Black, David >> Sent: Thursday, August 14, 2014 9:16 AM >> To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de >> Cc: dart@ietf.org; Black, David >> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2) >> >> Wearing none of my hats, I would prefer to put Gorry's item (2) into a >> TSV >> (Transport Area) draft somewhere, and hence prefer the suggestion to say >> that this document does not provide that sort of guidance. >> >> > > (2) I don't know if the document's goal is also to make transport >> > > recommendations for using multiple code points - i.e., things such >> as must >> > > be robust to the network changing a DSCP; needs to independently >> verify >> > > that a particular DCSP is not being black-holed, needs to not imply >> > > relative precedence when interpreting loss or marking of packets for >> a >> > > flow using multiple DCSPs etc. ??? >> > > >> > > If these are out of scope, then maybe the document should say that >> this >> > > particular document does not provide this sort of guidance. >> >> Thanks, >> --David >> >> > -----Original Message----- >> > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of >> gorry@erg.abdn.ac.uk >> > Sent: Thursday, August 14, 2014 9:06 AM >> > To: Ruediger.Geib@telekom.de >> > Cc: gorry@erg.abdn.ac.uk; dart@ietf.org >> > Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >> > >> > Thanks >> > >> > When I said "transport" I was thinking of the algorithms to be used in >> the >> > end-host to figure out what was operational and where congestion and >> delay >> > were experienced. But what you say is all an import part. I expect >> what >> > you discuss, could go into the tsvwg intercom draft. >> > >> > >> > Gorry >> > > Hi Gorry, >> > > >> > > the following text will likely appear in the next version of my >> > > diffserv-intercon draft. The more DSCPs appear in a flow which >> aren't >> > > deployed end-to-end for the corresponding PHB, the more often one of >> the >> > > scenarios will be encountered. >> > > >> > > The following scenarios start from a domain sending >> > > IP traffic using a PHB and a corresponding DSCP to an interconnected >> > > domain. The receiving domain may >> > > - Support the PHB and offer the same corresponding DSCP >> > > - Not support the PHB and use the DSCP for a different PHB >> > > - Not support the PHB and not use the DSCP >> > > - Support the PHB with a differing DSCP, and the DSCP of the >> > > sending domain is not used for another PHB >> > > - Support the PHB with a differing DSCP, and the DSCP of the >> > > sending domain is used for another PHB >> > > >> > > Another question to be answered then is how a network provider will >> treat >> > > unrecognized or unexpected DSCPs received at network boundaries. >> > > >> > > Regards, >> > > >> > > Ruediger >> > > >> > > >> > > -----Ursprngliche Nachricht----- >> > > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Gorry >> Fairhurst >> > > Gesendet: Mittwoch, 13. August 2014 22:33 >> > > An: dart@ietf.org >> > > Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >> > > >> > > >> > > I can see good points raised on the details, instead I have some >> questions >> > > about the overall document strcuture: >> > > >> > > [snip] >> > > >> > > (2) I don't know if the document's goal is also to make transport >> > > recommendations for using multiple code points - i.e.things such as >> must >> > > be robust to the network changing a DSCP; needs to independently >> verify >> > > that a particular DCSP is not being black-holed, needs to not imply >> > > relative precedence when interpreting loss or marking of packets for >> a >> > > flow using multiple DCSPs etc. ??? >> > > >> > > If these are out of scope, then maybe the document should say that >> this >> > > particular document does not provide this sort of guidance. >> > > >> > > Gorry >> > > >> > > _______________________________________________ >> > > Dart mailing list >> > > Dart@ietf.org >> > > https://www.ietf.org/mailman/listinfo/dart >> > > >> > >> > _______________________________________________ >> > Dart mailing list >> > Dart@ietf.org >> > https://www.ietf.org/mailman/listinfo/dart > From nobody Fri Aug 22 12:33:41 2014 Return-Path: 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 C91E51A0466 for ; Fri, 22 Aug 2014 12:33:40 -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 uM2VRvhungQK for ; Fri, 22 Aug 2014 12:33:38 -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 94D431A056D for ; Fri, 22 Aug 2014 12:33:38 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MJXX9S016697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2014 15:33:35 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s7MJXX9S016697 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408736015; bh=fDCWiQAAEvv17gvcBv6YxcVRTW4=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=g5+iDeEvLvCCipvpmXRDjmaGuG/vTl1wK29oI7CRAHxqozLbIhc7hDVFyGBw9H1Fh 0zr+/DtTWK+1NrTMaw0hf4JGMqm8e750RI5xTVVS/IQQuKTs7VAAHFoZc099kJ7P8Z v7FB6Zlx3W0VwXBRbNxJmMt9lbYRNwhJKOY+Vjzc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s7MJXX9S016697 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd03.lss.emc.com (RSA Interceptor); Fri, 22 Aug 2014 15:33:10 -0400 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MJXC7k000666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 15:33:13 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Fri, 22 Aug 2014 15:33:12 -0400 From: "Black, David" To: "gorry@erg.abdn.ac.uk" Date: Fri, 22 Aug 2014 15:33:11 -0400 Thread-Topic: WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2) Thread-Index: Ac++PRtDlaBMOr9LRHGSyJa7OkEIFwAApslw Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42A64@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077B951FF0@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712077BB42A58@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: DLM_1, public, GIS Solicitation Archived-At: http://mailarchive.ietf.org/arch/msg/dart/SWLY5-oBbQDV1K0d6m75oJhptAM Cc: "dart@ietf.org" Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:33:41 -0000 Good, I added a few words to be more explicit when I put the text into my working version of -03: Guidance on transport protocol design and implementation to provide support for use of multiple PHBs and DSCPs in a transport protocol connection (e.g., DCCP) or transport protocol association (e.g., SCTP) is out of scope for this document. Thanks, --David > -----Original Message----- > From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > Sent: Friday, August 22, 2014 3:13 PM > To: Black, David > Cc: gorry@erg.abdn.ac.uk; dart@ietf.org; Black, David > Subject: RE: WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2) >=20 > I could live with that - it would be even nicer if we actually had a > document with set of recommendations to point to - but since we don't, > this seems an appropriate statement. >=20 > Gorry >=20 >=20 > > Here's the next to last paragraph in Section 5.3: > > > > SCTP [RFC4960] differs from TCP in a number of ways, including the > > ability to deliver messages in an order that differs from the order > > in which they were sent and support for unreliable streams. However= , > > SCTP performs congestion control and retransmission across the entir= e > > association, and not on a per-stream basis. Although there may be > > advantages to using multiple drop precedence across SCTP streams or > > within an SCTP stream that does not use reliable ordered delivery, > > there is no practical operational experience in doing so (e.g., the > > SCTP sockets API [RFC6458] does not support use of more than one DSC= P > > for an SCTP association). As a consequence, the impacts on SCTP > > protocol and implementation behavior are unknown and difficult to > > predict. Hence a single PHB and DSCP should be used for all packets > > in an SCTP association, independent of the number or nature of > > streams in that association. Similar reasoning applies to a DCCP > > connection; a single PHB and DSCP should be used because the scope o= f > > congestion control is the connection and there is no operational > > experience with using more than one PHB or DSCP. > > > > I propose to add the following new sentence as its own paragraph: > > > > Guidance on transport protocol design and implementation to provide > > support for use of multiple PHBs and DSCPs in a transport connection > > (e.g., DCCP) or association (e.g., SCTP) is out of scope for this > > document. > > > > I could add examples of topics that could be addressed, but would prefe= r > > to leave that to the actual design activity. > > > > Thanks, > > --David > > > > > >> -----Original Message----- > >> From: Black, David > >> Sent: Thursday, August 14, 2014 9:16 AM > >> To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de > >> Cc: dart@ietf.org; Black, David > >> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2) > >> > >> Wearing none of my hats, I would prefer to put Gorry's item (2) into a > >> TSV > >> (Transport Area) draft somewhere, and hence prefer the suggestion to s= ay > >> that this document does not provide that sort of guidance. > >> > >> > > (2) I don't know if the document's goal is also to make transport > >> > > recommendations for using multiple code points - i.e., things such > >> as must > >> > > be robust to the network changing a DSCP; needs to independently > >> verify > >> > > that a particular DCSP is not being black-holed, needs to not impl= y > >> > > relative precedence when interpreting loss or marking of packets f= or > >> a > >> > > flow using multiple DCSPs etc. ??? > >> > > > >> > > If these are out of scope, then maybe the document should say that > >> this > >> > > particular document does not provide this sort of guidance. > >> > >> Thanks, > >> --David > >> > >> > -----Original Message----- > >> > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of > >> gorry@erg.abdn.ac.uk > >> > Sent: Thursday, August 14, 2014 9:06 AM > >> > To: Ruediger.Geib@telekom.de > >> > Cc: gorry@erg.abdn.ac.uk; dart@ietf.org > >> > Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 > >> > > >> > Thanks > >> > > >> > When I said "transport" I was thinking of the algorithms to be used = in > >> the > >> > end-host to figure out what was operational and where congestion and > >> delay > >> > were experienced. But what you say is all an import part. I expect > >> what > >> > you discuss, could go into the tsvwg intercom draft. > >> > > >> > > >> > Gorry > >> > > Hi Gorry, > >> > > > >> > > the following text will likely appear in the next version of my > >> > > diffserv-intercon draft. The more DSCPs appear in a flow which > >> aren't > >> > > deployed end-to-end for the corresponding PHB, the more often one = of > >> the > >> > > scenarios will be encountered. > >> > > > >> > > The following scenarios start from a domain sending > >> > > IP traffic using a PHB and a corresponding DSCP to an interconnect= ed > >> > > domain. The receiving domain may > >> > > - Support the PHB and offer the same corresponding DSCP > >> > > - Not support the PHB and use the DSCP for a different PHB > >> > > - Not support the PHB and not use the DSCP > >> > > - Support the PHB with a differing DSCP, and the DSCP of the > >> > > sending domain is not used for another PHB > >> > > - Support the PHB with a differing DSCP, and the DSCP of the > >> > > sending domain is used for another PHB > >> > > > >> > > Another question to be answered then is how a network provider wil= l > >> treat > >> > > unrecognized or unexpected DSCPs received at network boundaries. > >> > > > >> > > Regards, > >> > > > >> > > Ruediger > >> > > > >> > > > >> > > -----Urspr=FCngliche Nachricht----- > >> > > Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Gorry > >> Fairhurst > >> > > Gesendet: Mittwoch, 13. August 2014 22:33 > >> > > An: dart@ietf.org > >> > > Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 > >> > > > >> > > > >> > > I can see good points raised on the details, instead I have some > >> questions > >> > > about the overall document strcuture: > >> > > > >> > > [snip] > >> > > > >> > > (2) I don't know if the document's goal is also to make transport > >> > > recommendations for using multiple code points - i.e.things such a= s > >> must > >> > > be robust to the network changing a DSCP; needs to independently > >> verify > >> > > that a particular DCSP is not being black-holed, needs to not impl= y > >> > > relative precedence when interpreting loss or marking of packets f= or > >> a > >> > > flow using multiple DCSPs etc. ??? > >> > > > >> > > If these are out of scope, then maybe the document should say that > >> this > >> > > particular document does not provide this sort of guidance. > >> > > > >> > > Gorry > >> > > > >> > > _______________________________________________ > >> > > Dart mailing list > >> > > Dart@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/dart > >> > > > >> > > >> > _______________________________________________ > >> > Dart mailing list > >> > Dart@ietf.org > >> > https://www.ietf.org/mailman/listinfo/dart > > >=20 From nobody Fri Aug 22 12:46:23 2014 Return-Path: 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 AC8991A065B for ; Fri, 22 Aug 2014 12:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 yDcpXxC-6c4u for ; Fri, 22 Aug 2014 12:46:18 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id E7C4F1A0B06 for ; Fri, 22 Aug 2014 12:46:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 342B57C3EC6 for ; Fri, 22 Aug 2014 21:46:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmWMJCJoRQmq for ; Fri, 22 Aug 2014 21:46:08 +0200 (CEST) Received: from [172.28.90.129] (unknown [74.125.122.49]) by mork.alvestrand.no (Postfix) with ESMTPSA id D40037C3EC9 for ; Fri, 22 Aug 2014 21:46:07 +0200 (CEST) Message-ID: <53F79DFE.6040807@alvestrand.no> Date: Fri, 22 Aug 2014 21:46:06 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: dart@ietf.org References: <8D3D17ACE214DC429325B2B98F3AE712077B951FF0@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712077BB42A58@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712077BB42A64@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BB42A64@MX15A.corp.emc.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/8FOeHJCYI4oL2jq1kyO3N3JTRwE Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:46:21 -0000 On 08/22/2014 09:33 PM, Black, David wrote: > Good, I added a few words to be more explicit when I put the text into > my working version of -03: > > Guidance on transport protocol design and implementation to > provide support for use of multiple PHBs and DSCPs in a > transport protocol connection (e.g., DCCP) or transport protocol > association (e.g., SCTP) is out of scope for this document. It would be nice to add "is a topic for future work", but forward-looking statements should be avoided in RFCs. They turn out to be embarassing down the road far too often.... (however, the WG could recommend to the ADs that this subject be pursued by someone, somewhere, at some time....) > > Thanks, > --David > >> -----Original Message----- >> From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] >> Sent: Friday, August 22, 2014 3:13 PM >> To: Black, David >> Cc: gorry@erg.abdn.ac.uk; dart@ietf.org; Black, David >> Subject: RE: WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2) >> >> I could live with that - it would be even nicer if we actually had a >> document with set of recommendations to point to - but since we don't, >> this seems an appropriate statement. >> >> Gorry >> >> >>> Here's the next to last paragraph in Section 5.3: >>> >>> SCTP [RFC4960] differs from TCP in a number of ways, including the >>> ability to deliver messages in an order that differs from the order >>> in which they were sent and support for unreliable streams. However, >>> SCTP performs congestion control and retransmission across the entire >>> association, and not on a per-stream basis. Although there may be >>> advantages to using multiple drop precedence across SCTP streams or >>> within an SCTP stream that does not use reliable ordered delivery, >>> there is no practical operational experience in doing so (e.g., the >>> SCTP sockets API [RFC6458] does not support use of more than one DSCP >>> for an SCTP association). As a consequence, the impacts on SCTP >>> protocol and implementation behavior are unknown and difficult to >>> predict. Hence a single PHB and DSCP should be used for all packets >>> in an SCTP association, independent of the number or nature of >>> streams in that association. Similar reasoning applies to a DCCP >>> connection; a single PHB and DSCP should be used because the scope of >>> congestion control is the connection and there is no operational >>> experience with using more than one PHB or DSCP. >>> >>> I propose to add the following new sentence as its own paragraph: >>> >>> Guidance on transport protocol design and implementation to provide >>> support for use of multiple PHBs and DSCPs in a transport connection >>> (e.g., DCCP) or association (e.g., SCTP) is out of scope for this >>> document. >>> >>> I could add examples of topics that could be addressed, but would prefer >>> to leave that to the actual design activity. >>> >>> Thanks, >>> --David >>> >>> >>>> -----Original Message----- >>>> From: Black, David >>>> Sent: Thursday, August 14, 2014 9:16 AM >>>> To: gorry@erg.abdn.ac.uk; Ruediger.Geib@telekom.de >>>> Cc: dart@ietf.org; Black, David >>>> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2) >>>> >>>> Wearing none of my hats, I would prefer to put Gorry's item (2) into a >>>> TSV >>>> (Transport Area) draft somewhere, and hence prefer the suggestion to say >>>> that this document does not provide that sort of guidance. >>>> >>>>>> (2) I don't know if the document's goal is also to make transport >>>>>> recommendations for using multiple code points - i.e., things such >>>> as must >>>>>> be robust to the network changing a DSCP; needs to independently >>>> verify >>>>>> that a particular DCSP is not being black-holed, needs to not imply >>>>>> relative precedence when interpreting loss or marking of packets for >>>> a >>>>>> flow using multiple DCSPs etc. ??? >>>>>> >>>>>> If these are out of scope, then maybe the document should say that >>>> this >>>>>> particular document does not provide this sort of guidance. >>>> Thanks, >>>> --David >>>> >>>>> -----Original Message----- >>>>> From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of >>>> gorry@erg.abdn.ac.uk >>>>> Sent: Thursday, August 14, 2014 9:06 AM >>>>> To: Ruediger.Geib@telekom.de >>>>> Cc: gorry@erg.abdn.ac.uk; dart@ietf.org >>>>> Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >>>>> >>>>> Thanks >>>>> >>>>> When I said "transport" I was thinking of the algorithms to be used in >>>> the >>>>> end-host to figure out what was operational and where congestion and >>>> delay >>>>> were experienced. But what you say is all an import part. I expect >>>> what >>>>> you discuss, could go into the tsvwg intercom draft. >>>>> >>>>> >>>>> Gorry >>>>>> Hi Gorry, >>>>>> >>>>>> the following text will likely appear in the next version of my >>>>>> diffserv-intercon draft. The more DSCPs appear in a flow which >>>> aren't >>>>>> deployed end-to-end for the corresponding PHB, the more often one of >>>> the >>>>>> scenarios will be encountered. >>>>>> >>>>>> The following scenarios start from a domain sending >>>>>> IP traffic using a PHB and a corresponding DSCP to an interconnected >>>>>> domain. The receiving domain may >>>>>> - Support the PHB and offer the same corresponding DSCP >>>>>> - Not support the PHB and use the DSCP for a different PHB >>>>>> - Not support the PHB and not use the DSCP >>>>>> - Support the PHB with a differing DSCP, and the DSCP of the >>>>>> sending domain is not used for another PHB >>>>>> - Support the PHB with a differing DSCP, and the DSCP of the >>>>>> sending domain is used for another PHB >>>>>> >>>>>> Another question to be answered then is how a network provider will >>>> treat >>>>>> unrecognized or unexpected DSCPs received at network boundaries. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Ruediger >>>>>> >>>>>> >>>>>> -----Ursprngliche Nachricht----- >>>>>> Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Gorry >>>> Fairhurst >>>>>> Gesendet: Mittwoch, 13. August 2014 22:33 >>>>>> An: dart@ietf.org >>>>>> Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 >>>>>> >>>>>> >>>>>> I can see good points raised on the details, instead I have some >>>> questions >>>>>> about the overall document strcuture: >>>>>> >>>>>> [snip] >>>>>> >>>>>> (2) I don't know if the document's goal is also to make transport >>>>>> recommendations for using multiple code points - i.e.things such as >>>> must >>>>>> be robust to the network changing a DSCP; needs to independently >>>> verify >>>>>> that a particular DCSP is not being black-holed, needs to not imply >>>>>> relative precedence when interpreting loss or marking of packets for >>>> a >>>>>> flow using multiple DCSPs etc. ??? >>>>>> >>>>>> If these are out of scope, then maybe the document should say that >>>> this >>>>>> particular document does not provide this sort of guidance. >>>>>> >>>>>> Gorry >>>>>> >>>>>> _______________________________________________ >>>>>> Dart mailing list >>>>>> Dart@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dart >>>>>> >>>>> _______________________________________________ >>>>> Dart mailing list >>>>> Dart@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dart > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart -- Surveillance is pervasive. Go Dark. From nobody Fri Aug 22 13:12:30 2014 Return-Path: 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 69E1E1A0B77; Fri, 22 Aug 2014 13:12:28 -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 1nakvOx-zamu; Fri, 22 Aug 2014 13:12:26 -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 E2C581A0B13; Fri, 22 Aug 2014 13:12:25 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MKCJxL026823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2014 16:12:20 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s7MKCJxL026823 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408738340; bh=g0LEEAbeiL0x5qlVrYlrS24CzJ0=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=KaAoe412suL5NqXBgo6BShHD0A7DXcAK2AZyBCqsfTBZnKbcFuxSnrPwF5RUNTr6b nhjHSyhU8yy4Tb3Xf6626/pGspsEbzpXkvqedHG06RWVYg018kgILH4ObvLgzcvu1X zo7Cp8hWMMhvHw/Jwhza12e0tQB9GLCorPkYT70g= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s7MKCJxL026823 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd06.lss.emc.com (RSA Interceptor); Fri, 22 Aug 2014 16:12:08 -0400 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MKCDb1013366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 16:12:13 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Fri, 22 Aug 2014 16:12:13 -0400 From: "Black, David" To: Colin Perkins , "dart@ietf.org" Date: Fri, 22 Aug 2014 16:12:11 -0400 Thread-Topic: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 Thread-Index: Ac++RVa30ZbqhMbvSbS28VmO3im/pA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42A7A@MX15A.corp.emc.com> 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: mailusrhubprd04.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Xr_GN7Rs2THIkW5RP7bzlSLtJlQ Cc: Ben Campbell , "avt@ietf.org WG" , "Paul E. Jones \(paulej@packetizer.com\)" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 20:12:28 -0000 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. =20 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 si= ngle > 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. :-) >=20 > The forward and reverse paths are not necessarily the same and there is > nothing one should assume about the reverse path to provide guidance abou= t > 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= . > =20 > Further, an RTCP packet might provide information related to several diff= erent > RTP packets. I certainly would not want to see one RTCP packet per RTP p= acket. I'll watch where that discussion goes before proposing text. Thanks, --David > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Monday, August 18, 2014 11:18 AM > To: dart@ietf.org > Cc: avt@ietf.org WG; Ben Campbell; draft-ietf-dart-dscp-rtp.all@tools.iet= f.org > Subject: Re: [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 >=20 > Hi, >=20 > [I'm not on the DART list, so please cc me in replies] >=20 > This draft looks good overall, but I did have some comments, primarily ab= out > the discussion of RTP multiplexing. >=20 > The four bullet points in Section 2.1 that follow "The RTCWEB protocol su= it > encompasses a number of forms of multiplexing" seem to confuse RTP sessio= ns, > RTCP, and transport-layer flows. I suggest they be changed to: >=20 > > 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 b= e > > multiplexed onto a single transport-layer flow, forming a single > > RTP session; > > > > 2. The RTP Control Protocol (RTCP) [RFC3550] may be multiplexed ont= o > > 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 describ= ed > > 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. >=20 > In the following paragraph (penultimate paragraph in Section 2.1), I sugg= est > changing "unidirectional UDP packet flow" to "transport-layer flow" since= it > will not be unidirectional (since RTCP also flows in the reverse directio= n), > and might not use UDP. >=20 > In the first paragraph of section 2.2, I suggest changing "multiplexed ov= er > RTP sessions" to "multiplexed in a single RTP session" and "multiplexing = of > source streams in RTP sessions" to "multiplexing of source streams in a s= ingle > RTP session". >=20 > 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 se= nt > 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 si= ngle > 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. >=20 > Editorial: the protocol is called WebRTC, but the working group is RTCWEB= . > Accordingly, I think all instances of "RTCWEB" in this draft need to chan= ge to > "WebRTC". >=20 > Cheers, > Colin >=20 >=20 >=20 >=20 >=20 > On 9 Aug 2014, at 19:48, Ben Campbell 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 consideration= s for > the use of DiffServ code points in situations where one multiplexes multi= ple > RTP packet streams, and potentially other protocol streams, that share th= e > same 5-tuple. > > > > Since this draft is likely of interest to several working groups, I wou= ld > like to solicit additional reviews from participants of TSVWG, AVTCORE, > MMUSIC, CLUE, RTCWEB, and RMCAT. Please send any feedback (including feed= back > to the effect of "this is ready to progress") to the DART working group > mailing list. > > > > Thanks! > > > > Ben. > > > > Begin forwarded message: > > > >> Resent-From: draft-alias-bounces@tools.ietf.org > >> From: Ben Campbell > >> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 > >> Date: August 9, 2014 at 12:50:16 PM CDT > >> Resent-To: ben@nostrum.com, david.black@emc.com, paulej@packetizer.com > >> To: dart@ietf.org > >> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com, > Richard Barnes > >> > >> 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 t= o the > authors and the DART mailing list. If you've reviewed it and think it's g= ood > to go, please say so. > >> > >> Thanks! > >> > >> Ben. > >> > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 From nobody Fri Aug 22 13:28:01 2014 Return-Path: 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 0B5D71A0682; Fri, 22 Aug 2014 13:28:01 -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 UiOqNAOgt6t2; Fri, 22 Aug 2014 13:27:59 -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 EABC81A06C0; Fri, 22 Aug 2014 13:27:58 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MKRsPI030820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2014 16:27:54 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s7MKRsPI030820 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408739275; bh=wSFrxb7gPvz95v9//OXJLDGuK3M=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=kut0RRoE0341LRh4js+UbDCVdGjPWueST3uxO9VUBw4SzmrhwyxyyoO/1N1Q8uG7Z 1Vvd1nvctW+mQoFAr+8J3oVCbrlqH8iycPXqUEQlOp7gzY2DZ4Jo03/GaiH8tArJCw 44ZFwC6zkV+2i0vtVNNenPfJ+/lzVawusD/0m2H4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s7MKRsPI030820 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Fri, 22 Aug 2014 16:27:40 -0400 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MKRixh012085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 16:27:44 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Fri, 22 Aug 2014 16:27:44 -0400 From: "Black, David" To: Ben Campbell , Colin Perkins Date: Fri, 22 Aug 2014 16:27:43 -0400 Thread-Topic: WGLC: draft-ietf-dart-dscp-rtp-02 - proposed text for section 2.1 mux items 3 and 4 Thread-Index: Ac++R4bkunELpkmtSCSVGR/gKcaoAg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42A80@MX15A.corp.emc.com> 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: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/GNC8bCFHkSW46USj5Q-LRmU5yV8 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - proposed text for section 2.1 mux items 3 and 4 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 20:28:01 -0000 Section 2.1 of the draft currently has this text on WebRTC multiplexing: 3. An RTP session could 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. That text has at least a couple of problems: - This list is about WebRTC, so item 3 ought to specifically focus on the WebRTC data channel. - STUN doesn't encapsulate WebRTC traffic (TURN does). On the latter, for simplicity, I plan to remove the mention of encapsulation from here and deal with it elsewhere as part of discussion of what happens if TURN decides to send all the traffic over TCP (that'll be in a separate message, stay tuned). Proposed new text (merging item 4 into item 3, which aligns with the structure of RFC 5764 and the rfc5764-mux-fixes draft): 3. An RTP session could be multiplexed with a single SCTP over DTLS association plus signaling traffic for STUN [RFC5389] and TURN [RFC5766] into a single transport level flow as described in [RFC5764] and [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]. STUN and TURN are used for NAT traversal. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Thursday, August 21, 2014 9:06 PM > To: Ben Campbell; Colin Perkins > Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org; dart@ietf.org; avt@ietf.= org > WG; Black, David > Subject: RE: [Dart] [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 >=20 > Colin - many thanks for the review. I'll pick up your proposed changes, > perhaps > with minor edits. >=20 > Ben, >=20 > > >> 3. The RTP and RTCP traffic can be multiplexed with other protoco= ls > > >> via UDP encapsulation over a common pair of UDP ports as descr= ibed > > >> in [RFC5764] as updated by > > >> [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]; and > > > > Can we clarify what "other protocols" are expected? Are we just talking > about > > WebRTC data-channels over SCTP/DTLS, or other things? If the latter, ar= e we > > talking things we expect to do today, or in immediate futures, or exten= sions > > that might happen someday? >=20 > WebRTC will only multiplex its data channels, and this numbered list is a= bout > WebRTC, so this text should focus on those data channels - I'll revise th= e > draft > accordingly. >=20 > Other text elsewhere in the draft is broader (e.g., SCTP/UDP without DTLS= , > which > is of interest, even though WebRTC always uses DTLS). >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Ben Campbell > > Sent: Monday, August 18, 2014 4:48 PM > > To: Colin Perkins > > Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org; dart@ietf.org; avt@iet= f.org > > WG > > Subject: Re: [Dart] [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 > > > > Hi, > > > > I concur with all of Colin's comments, save one question below: > > > > On Aug 18, 2014, at 10:17 AM, Colin Perkins wrote: > > > > > 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, primaril= y > about > > the discussion of RTP multiplexing. > > > > > > The four bullet points in Section 2.1 that follow "The RTCWEB protoco= l > suit > > encompasses a number of forms of multiplexing" seem to confuse RTP sess= ions, > > > 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 individua= l > > >> RTP streams. These RTP streams can be multiplexed onto a singl= e > > >> 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 sing= le > > >> RTP session; > > >> > > >> 2. The RTP Control Protocol (RTCP) [RFC3550] may be multiplexed o= nto > > >> 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 protoco= ls > > >> via UDP encapsulation over a common pair of UDP ports as descr= ibed > > >> in [RFC5764] as updated by > > >> [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]; and > > > > Can we clarify what "other protocols" are expected? Are we just talking > about > > WebRTC data-channels over SCTP/DTLS, or other things? If the latter, ar= e we > > talking things we expect to do today, or in immediate futures, or exten= sions > > that might happen someday? > > > > >> > > >> 4. The data may be further encapsulated via STUN [RFC5389] and TU= RN > > >> [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" sin= ce it > > will not be unidirectional (since RTCP also flows in the reverse direct= ion), > > and might not use UDP. > > > > > > In the first paragraph of section 2.2, I suggest changing "multiplexe= d > over > > RTP sessions" to "multiplexed in a single RTP session" and "multiplexin= g 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". Th= ere > is > > no such thing. Rather, within a single RTP session there are RTCP packe= ts > sent > > that give information about the RTP streams that are being sent, and th= at > > 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 sens= e, > 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 chos= en > with > > care to avoid biasing that estimate too much. > > > > > > Editorial: the protocol is called WebRTC, but the working group is RT= CWEB. > > Accordingly, I think all instances of "RTCWEB" in this draft need to ch= ange > to > > "WebRTC". > > > > > > Cheers, > > > Colin > > > > > > > > > > > > > > > > > > On 9 Aug 2014, at 19:48, Ben Campbell wrote: > > >> Hi, > > >> > > >> The DART working group has started a last call for draft-ietf-dart-d= scp- > > 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, th= at > > 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: draft-alias-bounces@tools.ietf.org > > >>> From: Ben Campbell > > >>> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 > > >>> Date: August 9, 2014 at 12:50:16 PM CDT > > >>> Resent-To: ben@nostrum.com, david.black@emc.com, paulej@packetizer.= com > > >>> To: dart@ietf.org > > >>> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com= , > > Richard Barnes > > >>> > > >>> 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 comment= s 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 > > >> avt@ietf.org > > >> https://www.ietf.org/mailman/listinfo/avt > > > > > > > > > > > > -- > > > Colin Perkins > > > http://csperkins.org/ > > > > > > > > > > > > > _______________________________________________ > > Dart mailing list > > Dart@ietf.org > > https://www.ietf.org/mailman/listinfo/dart From nobody Fri Aug 22 13:37:05 2014 Return-Path: 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 ABD451A6F60 for ; Fri, 22 Aug 2014 13:37:02 -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 dc9Ny8HZh4-L for ; Fri, 22 Aug 2014 13:37:01 -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 1C7D71A6F5A for ; Fri, 22 Aug 2014 13:37:00 -0700 (PDT) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MKaxjU008735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Aug 2014 16:36:59 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s7MKaxjU008735 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408739819; bh=4TcwPupf7GUI2X255sNWfGpaZf0=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=MrpnPA0Ibgx0tR5g/o4+eWbDlmaUL5pWXcp/S3Nb4FEuBBoaqhDClJxT2v1zcCuqj WI2GS0Ekw08iK2yjhPT2nHbD5EJqFYD34gOvcW7GuHIfyx9OjzOKzfLgDT4Lq05zgt Ie/nn8WvWtLRJnKF/eFpzfHQP91Pv1YSixrb162M= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s7MKaxjU008735 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd56.lss.emc.com (RSA Interceptor) for ; Fri, 22 Aug 2014 16:36:38 -0400 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MKafki006790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Aug 2014 16:36:41 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub14.corp.emc.com ([128.222.70.235]) with mapi; Fri, 22 Aug 2014 16:36:41 -0400 From: "Black, David" To: "dart@ietf.org" Date: Fri, 22 Aug 2014 16:36:39 -0400 Thread-Topic: WGLC: draft-ietf-dart-dscp-rtp-02 - 5.1 DCCP corrections Thread-Index: Ac++SMQlqriD7A2iRjetRqIeIILtZQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42A85@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/3Akl1bp4wBni3FA_Md7cQvNXUYc Subject: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - 5.1 DCCP corrections X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 20:37:03 -0000 Someone was kind enough to privately point out an embarrassing DCCP thinko in Section 5.1: Unreliable datagram protocols (e.g., UDP, UDP-Lite, DCCP) are not sensitive to reordering in the network, because they do not provide reliable delivery or congestion control. =20 That one's my fault - of course DCCP provides congestion control. The above sentence will be changed to: UDP and UDP-Lite are not sensitive to reordering in the network, because they do not provide reliable delivery or congestion control. The DCCP reference will be moved earlier in the section - in this text: In addition, congestion control functionality in transport protocols usually infers congestion when packets are lost, creating an additional sensitivity to significant reordering - such reordering may be (mis-)interpreted as indicating congestion-caused packet loss, causing a reduction in transmission rate. "(including DCCP)" will be inserted after "in transport protocols". Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Fri Aug 22 14:24:54 2014 Return-Path: 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 7C8801A6F7C; Fri, 22 Aug 2014 14:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 d6SDj7p6u7bm; Fri, 22 Aug 2014 14:24:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303551A6F71; Fri, 22 Aug 2014 14:24:45 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7MLOOFK098518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Aug 2014 16:24:30 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BB42A80@MX15A.corp.emc.com> Date: Fri, 22 Aug 2014 16:24:23 -0500 X-Mao-Original-Outgoing-Id: 430435463.861963-c1f32629817d1baae36e0f8fafda5054 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712077BB42A80@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/TiIMEUi3Qgu2Z_HniEoSzkDzWJU Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , Colin Perkins , "avt@ietf.org WG" Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - proposed text for section 2.1 mux items 3 and 4 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 21:24:50 -0000 I agree except where noted inline: On Aug 22, 2014, at 3:27 PM, Black, David wrote: >=20 > Proposed new text (merging item 4 into item 3, which aligns with the > structure of RFC 5764 and the rfc5764-mux-fixes draft): >=20 > 3. An RTP session could be multiplexed with a single SCTP over DTLS > association plus signaling traffic for STUN [RFC5389] and TURN > [RFC5766] into a single transport level flow as described in > [RFC5764] and [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]. > STUN and TURN are used for NAT traversal. >=20 I agree with the direction here--but I'm not sure I would characterize = STUN and TURN as signaling traffic. And STUN is used for connectivity = checks, as well as NAT traversal. OTOH, maybe it would be better to just = for this section to just say that STUN and TURN can be multiplexed in = the flow without the additional comments about them? > Thanks, > --David >=20 >=20 >> -----Original Message----- >> From: Black, David >> Sent: Thursday, August 21, 2014 9:06 PM >> To: Ben Campbell; Colin Perkins >> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org; dart@ietf.org; = avt@ietf.org >> WG; Black, David >> Subject: RE: [Dart] [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 >>=20 >> Colin - many thanks for the review. I'll pick up your proposed = changes, >> perhaps >> with minor edits. >>=20 >> Ben, >>=20 >>>>> 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 >>>=20 >>> Can we clarify what "other protocols" are expected? Are we just = talking >> about >>> WebRTC data-channels over SCTP/DTLS, or other things? If the latter, = are we >>> talking things we expect to do today, or in immediate futures, or = extensions >>> that might happen someday? >>=20 >> WebRTC will only multiplex its data channels, and this numbered list = is about >> WebRTC, so this text should focus on those data channels - I'll = revise the >> draft >> accordingly. >>=20 >> Other text elsewhere in the draft is broader (e.g., SCTP/UDP without = DTLS, >> which >> is of interest, even though WebRTC always uses DTLS). >>=20 >> Thanks, >> --David >>=20 >>> -----Original Message----- >>> From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Ben Campbell >>> Sent: Monday, August 18, 2014 4:48 PM >>> To: Colin Perkins >>> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org; dart@ietf.org; = avt@ietf.org >>> WG >>> Subject: Re: [Dart] [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 >>>=20 >>> Hi, >>>=20 >>> I concur with all of Colin's comments, save one question below: >>>=20 >>> On Aug 18, 2014, at 10:17 AM, Colin Perkins = wrote: >>>=20 >>>> Hi, >>>>=20 >>>> [I'm not on the DART list, so please cc me in replies] >>>>=20 >>>> This draft looks good overall, but I did have some comments, = primarily >> about >>> the discussion of RTP multiplexing. >>>>=20 >>>> 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: >>>>=20 >>>>> The RTP streams that comprise a WebRTC session can be multiplexed >>>>> together in a number of ways: >>>>>=20 >>>>> 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; >>>>>=20 >>>>> 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; >>>>>=20 >>>>> 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 >>>=20 >>> Can we clarify what "other protocols" are expected? Are we just = talking >> about >>> WebRTC data-channels over SCTP/DTLS, or other things? If the latter, = are we >>> talking things we expect to do today, or in immediate futures, or = extensions >>> that might happen someday? >>>=20 >>>>>=20 >>>>> 4. The data may be further encapsulated via STUN [RFC5389] and = TURN >>>>> [RFC5766] for NAT (Network Address Translator) traversal. >>>>=20 >>>> 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. >>>>=20 >>>> 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". >>>>=20 >>>> 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. >>>>=20 >>>> 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". >>>>=20 >>>> Cheers, >>>> Colin >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 9 Aug 2014, at 19:48, Ben Campbell wrote: >>>>> Hi, >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>> Ben. >>>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>>> Resent-From: draft-alias-bounces@tools.ietf.org >>>>>> From: Ben Campbell >>>>>> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 >>>>>> Date: August 9, 2014 at 12:50:16 PM CDT >>>>>> Resent-To: ben@nostrum.com, david.black@emc.com, = paulej@packetizer.com >>>>>> To: dart@ietf.org >>>>>> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, = mls.ietf@gmail.com, >>> Richard Barnes >>>>>>=20 >>>>>> 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: >>>>>>=20 >>>>>> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Thanks! >>>>>>=20 >>>>>> Ben. >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Audio/Video Transport Core Maintenance >>>>> avt@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/avt >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Colin Perkins >>>> http://csperkins.org/ >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Dart mailing list >>> Dart@ietf.org >>> https://www.ietf.org/mailman/listinfo/dart From nobody Fri Aug 22 14:29:31 2014 Return-Path: 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 D466B1A6F4B for ; Fri, 22 Aug 2014 14:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 flzmmK04MxCx for ; Fri, 22 Aug 2014 14:29:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570731A6F57 for ; Fri, 22 Aug 2014 14:29:29 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7MLTL04098973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Aug 2014 16:29:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Fri, 22 Aug 2014 16:29:20 -0500 X-Mao-Original-Outgoing-Id: 430435760.787966-d4f1eaa1b771b35ce67fea0d74831170 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: dart@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/kQDuJ_GqEx7COMshOGfAuvtFqG4 Cc: Richard Barnes , draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 21:29:31 -0000 Hi, The WGLC concludes today. Thank's to everyone who made comments I understand that David will publish a new version in the next few days, = incorporating the WGLC feedback. Everyone who commented, please check = that version when it comes out and let us know if it reasonably = addresses your feedback. If all goes well, we will hand this off to the = IESG shortly afterwards. Thanks! Ben. On Aug 9, 2014, at 12:50 PM, Ben Campbell wrote: > 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: >=20 > https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >=20 > 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. >=20 > Thanks! >=20 > Ben. >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Fri Aug 22 14:42:55 2014 Return-Path: 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 A86D61A0AFB for ; Fri, 22 Aug 2014 14:42:54 -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 LMKSoGjskiV5 for ; Fri, 22 Aug 2014 14:42:52 -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 1E7971A03FA for ; Fri, 22 Aug 2014 14:42:51 -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 s7MLgohZ028253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Aug 2014 17:42:50 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s7MLgohZ028253 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408743770; bh=5DEpVB3mkNT5aGBylnnQTd3k7rI=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=H88hTkbBWiaznuA1QNNuxO5v2EuX1z0Z7k9K5WfxKvHYTToh+MQpWWlvyMuhGMI36 VbvBMGPMC3BvMYV/i0+ZZch0FQN45HkaGFFgQvxmvkwB4PgUDDQo8YlaZjQnAq8Byc mMoqgpSgNpCcnBmF5Sw8bE0w5jRNU/+AxjUZDxAw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s7MLgohZ028253 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd06.lss.emc.com (RSA Interceptor) for ; Fri, 22 Aug 2014 17:42:37 -0400 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MLghZE027948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Aug 2014 17:42:43 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Fri, 22 Aug 2014 17:42:42 -0400 From: "Black, David" To: "dart@ietf.org" Date: Fri, 22 Aug 2014 17:42:42 -0400 Thread-Topic: dscp-rtp draft WGLC: Coupled congestion controller text Thread-Index: Ac++UgB92GBEr2BIQDK2XZT+AcmUlg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42A8B@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/1JNyM6ctimkEBhpN-kbSeABORD8 Cc: "Black, David" Subject: [Dart] dscp-rtp draft WGLC: Coupled congestion controller text X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 21:42:54 -0000 In addition to his helpful comments to the list, Colin Perkins sent me a private suggestion to double check the DART dscp-rtp draft text against this requirement in Section 2 of draft-ietf-rmcat-cc-requirements-05.txt on Congestion Control Requirements For RMCAT: 9. Flows managed by this algorithm and flows competing against at a bottleneck may have different DSCP[RFC5865] markings depending on the type of traffic, or may be subject to flow-based QoS. A particular bottleneck or section of the network path may or may not honor DSCP markings. The algorithm should attempt to leverage DSCP markings when they're available. I think the DART dscp-rtp draft text is ok wrt that RMCAT draft text, as the RMCAT draft uses the unmodified word "flow" and hence is silent on presence, absence, and/or scope of multiplexing. It's also the case that the DART draft is supposed to document the present state of things, whereas this RMCAT requirements draft concerns future congestion control mechanisms. OTOH, the text in the DART draft on coupled congestion controllers appears to be somewhat off, as the guideline on avoidance of reordering within the scope of a common (coupled) congestion controller only applies when all bottlenecks are assumed to be shared, as opposed to when measurements are used to detect them. That makes the second half of the first guideline bullet in Section 6 too broad, and may suggest some additional edits to the text on shared bottleneck detection in Section 5.1. Here are the text changes that should correct this situation: -- Section 5.1 OLD Shared bottlenecks can be detected via correlations of measured metrics such as one-way delay. An alternative approach assumes that the set of packets on a single 5-tuple marked with DSCPs that do not allow reordering will utilize a common network path and common forwarding resources at each network node. NEW Shared bottlenecks can be detected via techniques such as correlation of one-way delay measurements across RTP streams. An alternate approach is to assume that the set of packets on a single 5-tuple marked with DSC= Ps that do not allow reordering will utilize a common network path and comm= on forwarding resources at each network node. -- Section 6 After: o Should not use different PHBs and DSCPs that allow reordering within a single RTP stream. If this is not done, significant network reordering may overwhelm implementation assumptions about reordering limits, e.g., jitter buffer size, causing poor user experiences, see Section 5.2 above. OLD When a common (coupled) congestion controller is used across multiple RTP streams, this recommendation against use of PHBs and DSCPs that allow reordering applies across all of the RTP streams that are within the scope of a single common (coupled) congestion controller. NEW This guideline applies to all of the RTP streams that are within the scope of a common (coupled) congestion controller that does not use per-RTP-stream measurements for bottleneck detection. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Fri Aug 22 14:47:26 2014 Return-Path: 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 8CB441A0AFB; Fri, 22 Aug 2014 14:47:24 -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 kUiWP6-FpC_b; Fri, 22 Aug 2014 14:47:22 -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 CB6941A0ADA; Fri, 22 Aug 2014 14:47:21 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MLlE8e005683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2014 17:47:15 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7MLlE8e005683 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408744035; bh=AzwUlm1Rlkm9+0ET5+8Bvqjngso=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=q4toCeyoLO3laPR3Fzu478wv+B1HTyI52+RUHT805HEZ2G1bWalHJMZ53vUJ8NEXU S9pfU326JegE/FeS5FIzWBCGMveXVw4BZSwQJ9bQ/hwrhcxLmEXLV0FNty2huUAHr1 GaXhqalrDXA1mUgWNiQIz0AibGfR3tiePEuWP/M8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7MLlE8e005683 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 22 Aug 2014 17:47:01 -0400 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7MLi3dM013710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 17:47:04 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub36.corp.emc.com ([::1]) with mapi; Fri, 22 Aug 2014 17:45:22 -0400 From: "Black, David" To: Ben Campbell Date: Fri, 22 Aug 2014 17:45:20 -0400 Thread-Topic: WGLC: draft-ietf-dart-dscp-rtp-02 - proposed text for section 2.1 mux items 3 and 4 Thread-Index: Ac++T4BcBDW6TNzeTgeNv8mi1heo/gAApazw Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42A8C@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BB42A80@MX15A.corp.emc.com> In-Reply-To: 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: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/dfhaH6uCfGFRQek3Q6ghyWjkXt0 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , Colin Perkins , "avt@ietf.org WG" Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - proposed text for section 2.1 mux items 3 and 4 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 21:47:24 -0000 Ok, "signaling traffic for STUN [RFC5389] and TURN [RFC5766]" --> "STUN [RFC5389] and TURN [RFC5766] traffic" It's even fewer words ;-) - consider that done. Thanks, --David > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Friday, August 22, 2014 5:24 PM > To: Black, David > Cc: Colin Perkins; draft-ietf-dart-dscp-rtp.all@tools.ietf.org; dart@ietf= .org; > avt@ietf.org WG > Subject: Re: WGLC: draft-ietf-dart-dscp-rtp-02 - proposed text for sectio= n 2.1 > mux items 3 and 4 >=20 > I agree except where noted inline: >=20 > On Aug 22, 2014, at 3:27 PM, Black, David wrote: >=20 > > > > Proposed new text (merging item 4 into item 3, which aligns with the > > structure of RFC 5764 and the rfc5764-mux-fixes draft): > > > > 3. An RTP session could be multiplexed with a single SCTP over DTLS > > association plus signaling traffic for STUN [RFC5389] and TURN > > [RFC5766] into a single transport level flow as described in > > [RFC5764] and [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]. > > STUN and TURN are used for NAT traversal. > > >=20 > I agree with the direction here--but I'm not sure I would characterize ST= UN > and TURN as signaling traffic. And STUN is used for connectivity checks, = as > well as NAT traversal. OTOH, maybe it would be better to just for this se= ction > to just say that STUN and TURN can be multiplexed in the flow without the > additional comments about them? >=20 >=20 > > Thanks, > > --David > > > > > >> -----Original Message----- > >> From: Black, David > >> Sent: Thursday, August 21, 2014 9:06 PM > >> To: Ben Campbell; Colin Perkins > >> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org; dart@ietf.org; > avt@ietf.org > >> WG; Black, David > >> Subject: RE: [Dart] [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 > >> > >> Colin - many thanks for the review. I'll pick up your proposed change= s, > >> perhaps > >> with minor edits. > >> > >> Ben, > >> > >>>>> 3. The RTP and RTCP traffic can be multiplexed with other protoco= ls > >>>>> via UDP encapsulation over a common pair of UDP ports as descr= ibed > >>>>> in [RFC5764] as updated by > >>>>> [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]; and > >>> > >>> Can we clarify what "other protocols" are expected? Are we just talki= ng > >> about > >>> WebRTC data-channels over SCTP/DTLS, or other things? If the latter, = are > we > >>> talking things we expect to do today, or in immediate futures, or > extensions > >>> that might happen someday? > >> > >> WebRTC will only multiplex its data channels, and this numbered list i= s > about > >> WebRTC, so this text should focus on those data channels - I'll revise= the > >> draft > >> accordingly. > >> > >> Other text elsewhere in the draft is broader (e.g., SCTP/UDP without D= TLS, > >> which > >> is of interest, even though WebRTC always uses DTLS). > >> > >> Thanks, > >> --David > >> > >>> -----Original Message----- > >>> From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Ben Campbell > >>> Sent: Monday, August 18, 2014 4:48 PM > >>> To: Colin Perkins > >>> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org; dart@ietf.org; > avt@ietf.org > >>> WG > >>> Subject: Re: [Dart] [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 > >>> > >>> Hi, > >>> > >>> I concur with all of Colin's comments, save one question below: > >>> > >>> On Aug 18, 2014, at 10:17 AM, Colin Perkins wrote= : > >>> > >>>> 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, primari= ly > >> about > >>> the discussion of RTP multiplexing. > >>>> > >>>> The four bullet points in Section 2.1 that follow "The RTCWEB protoc= ol > >> 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 individua= l > >>>>> RTP streams. These RTP streams can be multiplexed onto a singl= e > >>>>> 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 sing= le > >>>>> RTP session; > >>>>> > >>>>> 2. The RTP Control Protocol (RTCP) [RFC3550] may be multiplexed o= nto > >>>>> 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 protoco= ls > >>>>> via UDP encapsulation over a common pair of UDP ports as descr= ibed > >>>>> in [RFC5764] as updated by > >>>>> [I-D.petithuguenin-avtcore-rfc5764-mux-fixes]; and > >>> > >>> Can we clarify what "other protocols" are expected? Are we just talki= ng > >> about > >>> WebRTC data-channels over SCTP/DTLS, or other things? If the latter, = are > we > >>> talking things we expect to do today, or in immediate futures, or > extensions > >>> that might happen someday? > >>> > >>>>> > >>>>> 4. The data may be further encapsulated via STUN [RFC5389] and TU= RN > >>>>> [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" s= ince > 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 "multiplex= ed > >> over > >>> RTP sessions" to "multiplexed in a single RTP session" and "multiplex= ing > 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". T= here > >> is > >>> no such thing. Rather, within a single RTP session there are RTCP pac= kets > >> 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 se= nse, > >> but > >>> it's important to note that one role of RTCP is to provide an estimat= e of > >> the > >>> round-trip time seen by the media, so the PHB/DSCP will have to be ch= osen > >> 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 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 multiplex= es > >>> 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, AVTCOR= E, > >>> MMUSIC, CLUE, RTCWEB, and RMCAT. Please send any feedback (including > >> feedback > >>> to the effect of "this is ready to progress") to the DART working gro= up > >>> mailing list. > >>>>> > >>>>> Thanks! > >>>>> > >>>>> Ben. > >>>>> > >>>>> Begin forwarded message: > >>>>> > >>>>>> Resent-From: draft-alias-bounces@tools.ietf.org > >>>>>> From: Ben Campbell > >>>>>> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 > >>>>>> Date: August 9, 2014 at 12:50:16 PM CDT > >>>>>> Resent-To: ben@nostrum.com, david.black@emc.com, paulej@packetizer= .com > >>>>>> To: dart@ietf.org > >>>>>> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.co= m, > >>> Richard Barnes > >>>>>> > >>>>>> 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 commen= ts to > >>> the authors and the DART mailing list. If you've reviewed it and thin= k > it's > >>> good to go, please say so. > >>>>>> > >>>>>> Thanks! > >>>>>> > >>>>>> Ben. > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Audio/Video Transport Core Maintenance > >>>>> avt@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/avt > >>>> > >>>> > >>>> > >>>> -- > >>>> Colin Perkins > >>>> http://csperkins.org/ > >>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Dart mailing list > >>> Dart@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dart From nobody Fri Aug 22 17:03:54 2014 Return-Path: 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 C3B8B1A047C for ; Fri, 22 Aug 2014 17:03:52 -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 5VZ-FJsQQpVQ for ; Fri, 22 Aug 2014 17:03:50 -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 618C71A006A for ; Fri, 22 Aug 2014 17:03:50 -0700 (PDT) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7N03lQV008913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2014 20:03:47 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s7N03lQV008913 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408752228; bh=mgQbYRNpbQ26pebm9n2rOCJPAXY=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=GVuoy7yZnHly1cMSrmHcAUvyWpDCltA3CWhiNeseywYfdWBaZt5X/+FqNBZDPmrLN RFqU/teNB0WVLYjx8AnjV+mDPwJhDArDdNX3dKLkvAPgG9P0pwpxN7ZtdbGl130IvJ U3P+ZuxSJTAoqySGUEAxv9EuqUGlVAWnvSIeaMZY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s7N03lQV008913 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd53.lss.emc.com (RSA Interceptor); Fri, 22 Aug 2014 20:03:30 -0400 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7N03Vhi028454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 20:03:32 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub36.corp.emc.com ([::1]) with mapi; Fri, 22 Aug 2014 20:03:31 -0400 From: "Black, David" To: Ben Campbell , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Date: Fri, 22 Aug 2014 20:03:30 -0400 Thread-Topic: WGLC Comments on draft-ietf-dart-dscp-rtp-02 Thread-Index: Ac+7Lk/Kh7VfmlK4Q+mDJfprxveZggDLBkug Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42A9A@MX15A.corp.emc.com> References: <62D70F5C-C6CF-48C7-AE9F-55B17172555D@nostrum.com> In-Reply-To: <62D70F5C-C6CF-48C7-AE9F-55B17172555D@nostrum.com> 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: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/1PHBbRk6A_CfHO7XZ0kvy0a2XuE Cc: "Black, David" , "dart@ietf.org" Subject: Re: [Dart] WGLC Comments on draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 00:03:53 -0000 Ben, Many thanks for the extensive review - comments inline ... Could you suggest some additional text on context (WebRTC, clue and bundle) for the Introduction and Abstract, plus for a better example in Section 4? Thanks, --David > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Monday, August 18, 2014 5:49 PM > To: draft-ietf-dart-dscp-rtp.all@tools.ietf.org > Cc: dart@ietf.org > Subject: WGLC Comments on draft-ietf-dart-dscp-rtp-02 >=20 > (As individual) >=20 > Hi, >=20 > Here are some WGLC comments on draft-ietf-dart-dscp-rtp-02. >=20 > Thanks! >=20 > Ben. >=20 > ---------------- >=20 > **** Substantive: >=20 > -- General: >=20 > I was going to ask if we can be more precise on what sort of layering (an= d > muxing?) we expect to really happen on top of DTLS, especially for WebRTC= use > cases. But I think Colin's comments are on the right track, so I will com= ment > in that thread. Dealt with in other thread, on mux items 3 and 4 in Section 2.1. > -- Abstract (and intro) >=20 > It's probably worth mentioning that, other than mixing RTP/RTCP, RTP > multiplexing is a relatively new thing. It's needed by new work such as W= ebRTC > and clue, and it is enabled by bundle. The point being, this wasn't somet= hing > we really needed to worry about until now. Could you suggest text for the Introduction section, along with any additio= nal references? >=20 > -- Section 2.1, list item 3: "An RTP session could be multiplexed with ot= her > protocols ... " >=20 > What is likely to really happen here? I don't think we will see an arbitr= ary > mixing of other protocols in the immediate future. What are the realistic > constraints, and likely layerings? For example, with WebRTC, we are like= ly to > see some number of RTP/RTCP streams, stun, turn, and dtls, with dtls carr= ying > one or more SCTP associations (i.e. data channels) right? Do we have ways= to > signal more than that in sdp-bundle? >=20 > OTOH, I guess one could argue that people might try to mix in more things= in > the future. Dealt with in other thread. > -- 2.1, 2nd to last paragraph, last sentence (starting with "In contrast.= .." >=20 > Is this specific to SCTP associations carried over DTLS packets a la RFC5= 764, > or are we talking about SCTP/UDP in general? It's SCTP/UDP in general, clarified. >=20 > -- 2.2, third paragraph: >=20 > Are we talking about TCP as the outer transport protocol, and muxing thin= gs on > the TCP 5-tuple? Or are we considering TCP as something that might get > multiplexed on the UDP 5-tuple? Where do Jonathan Lennox's comments about > potentially falling back to an ICE TCP candidate fit? It's TCP as the outer transport protocol, and this is part of the text that responds to Jonathan Lennox's comments (the rest of it is hidden in 5.3, an= d needs some more prominence, as it's missing from the guidelines). I added: When TURN selects use of TCP, the entire real-time communications session is carried over a single TCP 5-tuple. And added mention of this scenario (TURN selects TCP) to the guideline on T= CP. =20 > -- section 3, paragraph 5: >=20 > Does the term "network node" include application endpoints that might do > initial DiffServ marking? No, changed to "node in the network". >=20 > -- section 3, paragraph 12: "... observable forwarding behavior (e.g., lo= ss, > delay, jitter) will often depend only on the relative loading of the link= " >=20 > Relative to what? Other links? Relative load to the capacity of the link? Removed "relative" ;-). >=20 > -- section 4: >=20 > It might be nice to have a more WebRTC-ish example. For example an audio > stream, video stream, and a data channel carrying something like a shared > white board or game. Sure, please send text. > -- section 6, last bullet: >=20 > Is there a such thing as "less than best effort traffic" where "best effo= rt" > treatments would be unacceptable? I can come up with possible examples - background bulk transfer of somethin= g large that should not interfere with foreground WebRTC data that is being carried as best-effort. >=20 > Actually, it's not clear to me from this paragraph if CS1 is ever appropr= iate, > at least from the application endpoint perspective, as it seem to give > completely unpredictable results. That was intended - would you like to see stronger language? > -- Normative References: >=20 > Are these first two references both "normative" enough to block on them? Well, the first one certainly is - if the relevant terminology in the rtp-grouping-taxonomy draft changes, this DART draft will change also, as has already been demonstrated. OTOH, I'll move both RFC 5764 and the rfc5764-mux-fixes draft to informativ= e. =20 > **** Editorial: >=20 > -- section 1, paragraph 1: "As a result use of different DSCPs..." >=20 > Missing comma after "result". Fixed. > -- 3.2, paragraph 1: "... and such nodes remark traffic ..." >=20 > May remark? Always remark? It's "may remark," but I rephrased for clarity - the sentence now reads: When DiffServ is used, the edge or boundary nodes of a network are responsible for ensuring that all traffic entering that network conforms to that network's policies for DSCP and PHB usage, and such nodes may change DSCP markings on traffic to achieve that result. =20 > -- 3.2, paragraph 3, last sentence: >=20 > Is this sentence redundant to the previous paragraph? Not completely, but I moved the point about ignoring embedded headers into the previous paragraph and removed this sentence. >=20 > -- 4, paragraph 1: 2nd and 3rd sentence >=20 > These sentences seem to contradict. The first says that receiving audio e= arly > is not useful, but the second says it may be useful. Changed second sentence to talk about increased reliability of receiving au= dio ... because more reliable arrival of audio helps assure smooth audio render= ing ... >=20 > -- 4, 2nd paragraph: "... e.g., are in an AF class ..." >=20 > in the _same_ AF class? Yes, changed to "a single AF class". >=20 > -- 5.1, 7th paragraph >=20 > Is this paragraph redundant with previous discussions of AF classes? I don't think the paragraph is redundant, but I removed "as the three PHBs in an AF class differ solely in drop precedence." as that is redundant with 3.1. >=20 > -- 5.2, third paragraph: >=20 > Can you elaborate on what it means to be "contained in a buffer"? Added: "because packets that arrive out of order are retrieved in order from the jitter buffer for rendering." >=20 > -- 5.2, around paragraph 5: >=20 > There are words about why non-interactive media is likely to have larger > jitter buffers, but the fact that interactive media may have smaller buff= ers > us left to implication. Elaborated first sentence in previous bullet - it now ends with "such as interactive conversations for which small jitter buffers are necessary to preserve human perceptions of real-time interaction." >=20 > -- 5.3, 1st and 2nd sentence: >=20 > These seem redundant to previous discussions about AF classes. Tightened up - the point about same forwarding resources implying no latenc= y variation needs to be made here. New text: Packets on the same 5-tuple that use PHBs within a single AF class can b= e expected to draw upon the same forwarding resources on network nodes (e.= g., use the same router queue) and hence use of multiple drop precedences wi= thin an AF class is not expected to cause latency variation. > -- 5.3, 2nd paragraph: >=20 > It's not clear to me what this paragraph means. Is drop likelihood the > likelihood that anything is dropped in a session, or the chance of any gi= ven > packet being dropped? I assume drop likelihood is relative to that of oth= er > sessions crossing the same path? And that under non congested conditions = none > of this will matter? Deleted second sentence, and rephrased first to: When PHBs within a single AF class are mixed within a flow, the resultin= g overall likelihood that packets will be dropped from that flow is a mix = of the drop likelihoods of the PHBs involved. I also joined it up w/the previous paragraph. >=20 >=20 > -- 6, 1st paragraph: " ... the following requirements ..." >=20 > Are these requirements per se, or guidelines? Guidelines. > -- 6, bullet list >=20 > Each bullet starts with a verb, but ommits the subject. E.g., in the firs= t > bullet, what is the actor that should not use different DSCPs within a > different stream? The subject was factored out - "applications and other traffic sources". I moved it to start a new paragraph. > -- 6, 1st bullet: >=20 > The double negation is confusing ("should not use", "If this is not > done..."). Also, Now reads: " Should limit use of DSCPs within a single RTP stream to those whose PHBs do not allow packet reordering." > 2nd bullet: >=20 > Is "use a single PHB and DSCP" different than just saying "use a single D= SCP"? The latter is better for "applications and other traffic sources" Extensiv= e editing resulted,. >=20 > 3rd bullet: >=20 > Am I correct in assuming SCTP multihoming is not an issue here? Should we > mention that explicitly? It's not an issue, and does not really need to be mentioned here. Switchin= g among addresses involved in SCTP multihoming is a transient affect akin to (and possibly caused by) routing changes, and that's already mentioned in Section 5.1. From nobody Fri Aug 22 18:10:15 2014 Return-Path: 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 B55F11A02FE for ; Fri, 22 Aug 2014 18:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.968 X-Spam-Level: X-Spam-Status: No, score=-4.968 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 KN7iGiustDLF for ; Fri, 22 Aug 2014 18:09:56 -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 64DE41A0258 for ; Fri, 22 Aug 2014 18:09:56 -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 s7N19pkm014308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2014 21:09:52 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7N19pkm014308 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408756192; bh=00IIlpwsPVMl172ExcASebasbW0=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=GGQTXozcJ8zc76l5Ikcj5hpOPCUmUBT1PPTVpjARgimayHbkFaVPwZ+l+NWxMC/kg Gg3DA0tldVIkhzS0WNEKrsetxNADcH1HhAUxE/feb525euAP8Bc/bM92EvE3K2ATYv t6e2VJpuOCvMTOmcUN79xmWxRL3q/3vA9W8RwO1k= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7N19pkm014308 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd56.lss.emc.com (RSA Interceptor); Fri, 22 Aug 2014 21:09:38 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7N19de8023342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 21:09:42 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Fri, 22 Aug 2014 21:09:39 -0400 From: "Black, David" To: Harald Alvestrand , "dart@ietf.org" Date: Fri, 22 Aug 2014 21:09:38 -0400 Thread-Topic: [Dart] HTA's Last Call review - drart-dscp-rtp-02 Thread-Index: Ac++D5lUIUoIk5vHRs+QsOwtNywGBgAVs8NA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42AA0@MX15A.corp.emc.com> References: <53F749D1.7050407@alvestrand.no> In-Reply-To: <53F749D1.7050407@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712077BB42AA0MX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/RCawZSZBaubQDbVS7rfzC57usrE Cc: "Black, David" Subject: Re: [Dart] HTA's Last Call review - drart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 01:10:00 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE712077BB42AA0MX15Acorpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGFyYWxkLA0KDQpUaGFuayB5b3UgZm9yIGNhcmVmdWxseSByZXZpZXdpbmcgdGhpcyBkcmFmdC4g IENvbW1lbnRzL3Jlc3BvbnNlcyBhcmUgaW5saW5lIGF0IERMQj4uDQoNCknigJltIGFib3V0IHRv IHBvc3QgYSAtMDMgdmVyc2lvbiB3aGljaCBpcyBub3QgY29tcGxldGVseSBkb25lLg0KDQpUaGFu a3MsDQotLURhdmlkDQoNCkZyb206IERhcnQgW21haWx0bzpkYXJ0LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBIYXJhbGQgQWx2ZXN0cmFuZA0KU2VudDogRnJpZGF5LCBBdWd1c3QgMjIs IDIwMTQgOTo0NyBBTQ0KVG86IGRhcnRAaWV0Zi5vcmcNClN1YmplY3Q6IFtEYXJ0XSBIVEEncyBM YXN0IENhbGwgcmV2aWV3IC0gZHJhcnQtZHNjcC1ydHAtMDINCg0KDQpMYXN0IENhbGwgcmV2aWV3 IC0gZHJhdC1pZXRmLWRhcnQtZHNjcC1ydHAtMDINCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1kYXJ0LWRzY3AtcnRwLTAyITxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAtMDI+DQoNCjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAtMDI+DQoNCg0KDQpTdW1tYXJ5OiBUaGlzIGRv Y3VtZW50IGlzIG5vdCByZWFkeSBmb3IgSUVURiBMYXN0IENhbGwsIGJ1dCBjbG9zZS4NCg0KVGhl IHJlY29tbWVuZGF0aW9ucyBhcmUgcmVhc29uYWJsZSBhbmQgcmVhc29uYWJseSBhcmd1ZWQsIGJ1 dCB0aGUgcHJlY2lzaW9uIGFuZCBzcGVjaWZpY2l0eSBvZiB0aGUgbGFuZ3VhZ2UgbmVlZHMgdG8g YmUgdGlnaHRlbmVkIHVwIGJlZm9yZSBwdWJsaWNhdGlvbi4NCg0KDQoNClRoZSBiZWxvdyBhZGRy ZXNzZXMgc29tZSBzcGVjaWZpYyBjb25jZXJucy4NCg0KDQoNClNlY3Rpb24gMg0KDQoNCg0Kbml0 OiDigJxjb21tdW5pY2F0aW9uIGluIHJlYWwtdGltZeKAnSAtPiDigJxjb21tdW5pY2F0aW9uIGlu IHJlYWwgdGltZeKAnQ0KDQpuaXQ6IFRoZSBjb21wbGV4IGV4YW1wbGUgbmVlZHMgdG8gbWVudGlv biB0aGF0IHRoZXJlIG1heSBiZSBub24tbWVkaWEgc3RyZWFtczsgc3VnZ2VzdCDigJx0aGVyZSBt YXkgYmUgbXVsdGlwbGUgbWVkaWEgYW5kIG5vbi1tZWRpYSBzdHJlYW1z4oCdLg0KDQoNCg0KRExC PiBGaXhlZCBib3RoLg0KDQoNCg0KMi4xDQoNCg0KDQpSZWZlcmVuY2UgdG8gU1NSQyBmb3IgcmVm ZXJlbmNlIGNsb2NrIGlzIHdyb25nIC0g4oCcYW4gUlRQIHN0cmVhbSBtYXkgY29udGFpbiBtdWx0 aXBsZSBzb3VyY2Ugc3RyZWFtcyB0aGF0IHVzZSB0aGUgc2FtZSByZWZlcmVuY2UgY2xvY2sgKFNT UkMp4oCdIC0gdGhpcyBzaG91bGQgYmUg4oCcY2xvY2ssIGlkZW50aWZpZWQgYnkgdGhlIHNhbWUg Q05BTUXigJ0uIFRoZSBTU1JDIGhhcyB0byBiZSBkaWZmZXJlbnQgZm9yIGVhY2ggUlRQIHN0cmVh bSBpbiBhbiBSVFAgc2Vzc2lvbi4gKFRoZSBuYW1pbmcgY2hvaWNlIGhlcmUgaXMgY29uZnVzaW5n 4oCmLikNCg0KDQoNCkRMQj4gVGhlIHRleHQgcmVmZXJzIHRvIGEgc2luZ2xlIFJUUCBzdHJlYW0g dGhhdCBjb250YWlucyBtdWx0aXBsZSBzb3VyY2Ugc3RyZWFtcywgYnV0IG9ubHkgb25lIFNTUkMu DQoNCkRMQj4gQXJlIHlvdSBzdXJlIHRoYXQgdGhpcyBuZWVkcyB0byBjaGFuZ2UgdG8gQ05BTUUg ZnJvbSBTU1JDPyAgSeKAmWQgcHJlZmVyIG5vdCB0byBpbnRyb2R1Y2UgdGhlIENOQU1FDQoNCkRM Qj4gY29uY2VwdCBpZiBpdOKAmXMgbm90IG5lY2Vzc2FyeS4NCg0KDQoNClRoZSBzZWN0aW9uIG5l ZWRzIHRvIG1lbnRpb24gdGhhdCBSVFAgY2FuIGJlIGNhcnJpZWQgb3ZlciBhIG5vbi1kYXRhZ3Jh bSBwcm90b2NvbCBzdWNoIGFzIFRDUCwgYnV0IHRoYXQgdGhpcyBkb2N1bWVudCBkb2VzIG5vdCBz YXkgbW9yZSBhYm91dCB0aGlzIC0ganVzdCB0byBzaG93IHRoYXQgaXRzIG9taXNzaW9uIGlzIGRl bGliZXJhdGUsIG5vdCBhY2NpZGVudGFsLg0KDQooSW4gZmFjdCA1LjMgZGlzY3Vzc2VzIFRDUC1l bmNhcHN1bGF0ZWQgUlRQLiBTbyBpdOKAmXMgYXBwcm9wcmlhdGUgdG8gbWVudGlvbiBpdCBoZXJl LikNCg0KDQoNCkRMQj4gRG9uZS4NCg0KDQoNClNUVU4gaXMgbm90IGFuIGVuY2Fwc3VsYXRpb24g cHJvdG9jb2wsIHNvIHNob3VsZCBiZSBvbWl0dGVkIGZyb20gdGhlIOKAnGVuY2Fwc3VsYXRlZCB2 aWEgU1RVTuKAnSBzZW50ZW5jZS4gVFVSTiBpcy4gU1RVTiBwYWNrZXRzIGFyZSwgaG93ZXZlciwg bXVsdGlwbGV4ZWQgd2l0aCB0aGUgUlRQIHBhY2tldHMuDQoNCg0KDQpETEI+IEFncmVlLCBzZWUg dGV4dCBpbiBzZXBhcmF0ZSBtZXNzYWdlLg0KDQoNCg0KQWdyZWUgdGhhdCB0aGUgVURQIHN0cmVh bSBpcyBub3QgdW5pZGlyZWN0aW9uYWwuDQoNCg0KDQpETEI+IEFncmVlLCBhbmQgcGlja2VkIHVw IENvbGlu4oCZcyBzdWdnZXN0ZWQgY2hhbmdlIGhlcmUuDQoNCg0KDQoyLjINCg0KDQoNClNUVU4v VFVSTiBwYXJhZ3JhcGggc2l0cyBvZGRseSBoZXJlLiBJdCBzZWVtcyB0byBiZWxvbmcgb3V0c2lk ZSB0aGUg4oCccmVhc29ucyBmb3IgbXVsdGlwbGV4aW5n4oCdIGZsb3cuIFBlcmhhcHMgbW92ZSBp dCB0byB0aGUgYmVnaW5uaW5nIG9mIHRoZSBzZWN0aW9uPw0KDQpBZ2FpbiwgU1RVTiBkZXNjcmlw dGlvbiBuZWVkcyB0dW5pbmc7IFNUVU4gaXMgdXNlZCBhbHNvIGZvciBlbmFibGluZyBjb21tdW5p Y2F0aW9uIHdpdGhvdXQgYSByZWxheSBzZXJ2ZXIsIGJ5IGV4Y2hhbmdpbmcgcHVibGljbHktdmlz aWJsZSBJUCBhZGRyZXNzZXMgYW5kIHBvcnRzLg0KDQoNCg0KRExCPiBPaywgSSBzZWUg4oCcc2l0 cyBvZGRseeKAnS4gIEnigJl2ZSBtb3ZlZCB0aGlzIHRleHQgaW50byBTZWN0aW9uIDIuMSBhbmQg YWRqdXN0ZWQgaXQgLSBzZWUgdGhlIC0wMyBkcmFmdCB3aGVuIGl04oCZcyBwb3N0ZWQuDQoNCg0K DQo0Lg0KDQoNCg0K4oCccmVjZWl2aW5nIHRoZSBhdWRpbyBwYWNrZXRzIGFoZWFkIG9mIHRoZSB2 aWRlbyBpcyBub3QgdXNlZnVs4oCdIC0+IOKAnGlzIG5vdCB2ZXJ5IHVzZWZ1bOKAnSAtIHRoZSBu ZXh0IHNlbnRlbmNlIGdpdmVzIGEgcmVhc29uIHdoeSBpdCBpcyBzb21ld2hhdCB1c2VmdWwuDQoN Cg0KDQpETEI+IENoYW5nZWQgdG8g4oCcc2lnbmlmaWNhbnRseSBhaGVhZOKAnSBhbmQgY2hhbmdl ZCBuZXh0IHNlbnRlbmNlIHRvIGJlIGFib3V0IHJlbGlhYmlsaXR5IGluc3RlYWQgb2YgdGltaW5n IChlYXJseSkuDQoNCg0KDQo1LjEgRGlmZnNlcnYsIFJlb3JkZXJpbmcgYW5kIFRyYW5zcG9ydCBQ cm90b2NvbHMNCg0KDQoNClRoZSBwYXJhZ3JhcGgg4oCcUmVvcmRlcmluZyBhbHNvIGFmZmVjdHMg b3RoZXIgZm9ybXMgb2YgY29uZ2VzdGlvbiBjb250cm9s4oCdIGlzIHdyb25nLiBUaGUgY29udGVu dCBpcyBPSywgYnV0IHRoZSBpbnRybyBpcyBub3QgLSBpdCBpcyB0aGUgZGlmZmVyZW50aWFsIHRy ZWF0bWVudCAoaW5jbHVkaW5nIGRyb3AgcHJvYmFiaWxpdHkpIHRoYXQgY3JlYXRlcyBwcm9ibGVt cyBmb3IgUk1DQVQsIG5vdCAoanVzdCkgdGhlIHJlb3JkZXJpbmcuDQoNCg0KDQpETEI+IEkgZG9u 4oCZdCB0aGluayBzby4gIElmIFJNQ0FUIGNhbuKAmXQgY29wZSB3aXRoIGEgdmlkZW8gc3RyZWFt IHRoYXQgdXNlcyBtdWx0aXBsZSBQSEJzIGZyb20gYW4gQUYgY2xhc3MsIHNvbWV0aGluZyBpcyB3 cm9uZy4NCg0KRExCPiBJ4oCZbGwgdGFnIHRoaXMgYXMgYW4gb3BlbiBpc3N1ZSBpbiB0aGUgZHJh ZnQgLSBjb3VsZCB5b3Ugc3RhcnQgYSBzZXBhcmF0ZSB0aHJlYWQgdGhhdCBpbmNsdWRlcyB0aGUg Uk1DQVQgV0cgdG8gc29ydCB0aGlzDQoNCkRMQj4gb3V0Pw0KDQoNCg0KRENDUCBpcyBzZW5zaXRp dmUgdG8gZGlmZmVyZW50aWFsIHRyZWF0bWVudCwgc2luY2UgaXQgZG9lcyBjb25nZXN0aW9uIGNv bnRyb2wsIHNvIGRlc2NyaXB0aW9uIG9mIGl0IGFzIOKAnHByb2JsZW0gZnJlZeKAnSBpcyB3cm9u Zy4NCg0KDQoNCkRMQj4gWXVwLCBzZXJpb3VzIHRoaW5rbyBieSB5b3VycyB0cnVseSwgc2VlIG90 aGVyIG1lc3NhZ2Ugb24gdGhhdCBzcGVjaWZpYyB0b3BpYyBmb3IgbmV3IHRleHQuDQoNCg0KDQpJ IHRoaW5rIHRoZXJlIGFyZSBjb25zaWRlcmF0aW9ucyBjb21pbmcgZnJvbSByZW9yZGVyaW5nICh3 aGljaCBhZmZlY3QgcHJvdG9jb2xzIHdpdGggaW1tZWRpYXRlIGZlZWRiYWNrLCBzdWNoIGFzIEFD Sy1iYXNlZCBwcm90b2NvbHMpLCBhbmQgdGhlcmUgYXJlIGNvbnNkaWVyYXRpb25zIGZyb20gZGlm ZXJlbnRpYWwgdHJlYXRtZW50IChndWVzc2luZyB3cm9uZyBhYm91dCB3aGF04oCZcyBhZmZlY3Rl ZCBieSBhIHF1ZXVlKS4gVGhlIGZvcm1lciBhcHBsaWVzIHRvIFRDUDsgdGhlIGxhdHRlciBhcHBs aWVzIHRvIFRDUCwgU0NUUCwgRENDUCwgYW5kIChwcm9iYWJseSkgd2hhdGV2ZXIgUk1DQVQgY29t ZXMgdG8uIFRoZXNlIHR3byBzaG91bGQgYmUgc2VwYXJhdGVkLg0KDQoNCg0KRExCPiBJ4oCZbSBu b3Qgc3VyZSB0aGF0IEkgdW5kZXJzdGFuZCB3aGF0IHlvdeKAmXJlIGFza2luZyBmb3IsIGFuZCBJ 4oCZbSBub3Qgc3VyZSB3aGV0aGVyIEkgYWdyZWUuICBJIGJlbGlldmUgdGhhdCBTQ1RQIGlzDQoN CkRMQj4gVENQLWxpa2UgaW4gYmVpbmcgQUNLLWJhc2VkLCBEQ0NQIGlzIGNvdmVyZWQgYnkgdGV4 dCBpbiB0aGUgb3RoZXIgbWVzc2FnZSBvbiB0aGF0IHRvcGljLCBhbmQg4oCcd2hhdGV2ZXIgUk1D QVQgY29tZXMgdG/igJ0NCg0KRExCPiBpcyBzcGVjdWxhdGl2ZSAoYWx0aG91Z2ggdGhlIGRyYWZ0 IGRvZXMgaGF2ZSB0ZXh0IG9uIE1pY2hhZWwgV2VsemzigJlzIGNvbmNlcm4gYWJvdXQgY291cGxl ZCBjb25nZXN0aW9uIGNvbnRyb2xsZXJzIHRoYXQNCg0KRExCPiBkb27igJl0IHVzZSBtZWFzdXJl bWVudHMgdG8gZGV0ZWN0IGJvdHRsZW5lY2tzKS4NCg0KDQoNCkRMQj4gSXMgdGhlcmUgc3BlY2lm aWMgdGV4dCBvbiB0aGlzIHRvcGljIHRoYXQgY2FuIGJlIGlkZW50aWZpZWQgYXMgd3Jvbmcgb3Ig bWlzbGVhZGluZyBhbmQgcHJvcG9zZWQgYWx0ZXJuYXRpdmUgdGV4dD8NCg0KDQoNCjUuMiBEaWZm U2VydiwgcmVvcmRlcmluZyBhbmQgcmVhbCB0aW1lIGNvbW11bmljYXRpb24NCg0KDQoNClRoZSBs YXN0IHBhcmFncmFwaCBvZiB0aGUgc2VjdGlvbiBpcyBzb21ld2hhdCBtaXNsZWFkaW5nIC0gbmV0 d29yayBwYWNrZXQgcmVvcmRlcmluZyBkb25lIGZvciAqd2hhdGV2ZXIqIHJlYXNvbiBoYXMgbm8g dXBwZXIgYm91bmQuIElmIHRoZSBhdXRob3JzIHRoaW5rIHRoYXQgcGFja2V0IHJlb3JkZXJpbmcg aXMgbW9yZSBsaWtlbHkgdG8gYmUgcHJvYmxlbWF0aWMgd2l0aCBkaWZmZXJlbnQgRFNDUHMgdGhh biB3aXRoIHRoZSBzYW1lIERTQ1AsIHRoYXTigJlzIHdoYXQgdGhleSBzaG91bGQgc2F5Lg0KDQoN Cg0KRExCPiBPaywgcGFyYWdyYXBoIG5vdyByZWFkczoNCg0KDQoNCiAgIE5ldHdvcmsgcGFja2V0 IHJlb3JkZXJpbmcgaGFzIG5vIGVmZmVjdGl2ZSB1cHBlciBib3VuZCwgYW5kIGNhbiBleGNlZWQg dGhlIHNpemUgb2YgYW55IHJlYXNvbmFibGUNCg0KICAgaml0dGVyIGJ1ZmZlci4gSW4gcHJhY3Rp Y2UsIHRoZSBzaXplIG9mIGppdHRlciBidWZmZXJzIGZvciByZXBsYXkgaXMgbGltaXRlZCBieSBl eHRlcm5hbCBmYWN0b3JzDQoNCiAgIHN1Y2ggYXMgdGhlIGFtb3VudCBvZiB0aW1lIHRoYXQgYSBo dW1hbiBpcyB3aWxsaW5nIHRvIHdhaXQgZm9yIHJlcGxheSB0byBzdGFydC4gIFVzZSBvZiBkaWZm ZXJlbnQNCg0KICAgRFNDUHMgdGhhdCBhbGxvdyByZW9yZGVyaW5nIGlzIG1vcmUgbGlrZWx5IHRv IGNhdXNlIHJlb3JkZXJpbmcgcHJvYmxlbXMgdGhhbiB1c2Ugb2YgYSBzaW5nbGUgRFNDUA0KDQog ICBvciBzZXQgb2YgRFNDUHMgdGhhdCBkb2VzIG5vdCBhbGxvdyByZW9yZGVyaW5nLg0KDQoNCg0K VGhlIHJlZmVyZW5jZSB0byBSVENQIG11bHRpLXN0cmVhbSBvcHRpbWl6YXRpb24gc2VlbXMgY29t cGxldGVseSB3cm9uZy4gVGhlIGdyb3VwaW5nIGludG8gUlRDUCByZXBvcnRpbmcgZ3JvdXBzIGlz IGFib3V0IHJlY2VpdmVyIFNTUkNzIHRoYXQgc2VlIHRoZSBzYW1lIHNldCBvZiBwYWNrZXRzLCBu b3QgYWJvdXQgZ3JvdXBpbmcgcmVwb3J0cyBhYm91dCBkaWZmZXJlbnQgU1NSQyB0b2dldGhlci4g KHVubGVzcyBJ4oCZdmUgbWlzdW5kZXJzdG9vZCBzb21ldGhpbmcpLiBXaGVuIG5vdCB1c2luZyBt dWx0aS1zdHJlYW0gb3B0aW1pemF0aW9uLCB0aGVzZSBTU1JDcyBzZW5kIGR1cGxpY2F0ZSByZXBv cnRzLg0KDQoNCg0KRExCPiBUaGUgREFSVCBkcmFmdCB0ZXh0IGRvZXMgbm90IG1lbnRpb24gU1NS Q3MsIGFuZCBhcHBlYXJzIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCBTZWN0aW9uIDMgYW5kIHRoZSBm aXJzdCBwYXJhZ3JhcGgNCg0KRExCPiBvZiBTZWN0aW9uIDMuMSBvZiBkcmFmdC1pZXRmLWF2dGNv cmUtcnRwLW11bHRpLXN0cmVhbS1vcHRpbWlzYXRpb24tMDMuICBUaGUgcG9pbnQgaXMgdGhhdCBh bnkgdXNlIG9mIGRpZmZlcmVudCBEU0NQcw0KDQpETEI+IGZvciBkaWZmZXJlbnQgUlRQIHN0cmVh bXMgYnJlYWtzIHRoZSAodHdpY2Utc3RhdGVkKSByZXF1aXJlbWVudCBpbiB0aGF0IEFWVENPUkUg ZHJhZnQgZm9yIGFuIGlkZW50aWNhbCB2aWV3IG9mIHRoZQ0KDQpETEI+IG5ldHdvcmsgY29uZGl0 aW9uc+KAnSBhY3Jvc3MgdGhlIFJUUCBzdHJlYW1zIGludm9sdmVkLCBlYWNoIG9mIHdoaWNoIGhh cyBpdHMgb3duIFNTUkMuDQoNCg0KDQpETEI+IEkgZG9u4oCZdCB0aGluayB0aGUgY3VycmVudCBE QVJUIGRyYWZ0IHRleHQgaXMgYWN0dWFsbHkgd3JvbmcsIGJ1dCBJ4oCZZCB3ZWxjb21lIGVkaXRp bmcgc3VnZ2VzdGlvbnMgdGhhdCBpbXByb3ZlIGNsYXJpdHkuDQoNCg0KDQo2LiBHdWlkZWxpbmVz DQoNCg0KDQpUaGUgd29yZCDigJxyZXF1aXJlbWVudHPigJ0gc2VlbXMgYXQgb2RkcyB3aXRoIHRo ZSBoZWFkbGluZSDigJxndWlkZWxpbmVz4oCdLg0KDQoNCg0KRExCPiBGaXhlZC4NCg0KDQoNClRo ZSB3b3JkIOKAnHNlc3Npb27igJ0gaXMgdXNlZCBzZXZlcmFsIHRpbWVzIHdpdGhvdXQgZXhwbGFu YXRpb24gLSDigJxSVENQIHNlc3Npb27igJ0sIOKAnHJlbGlhYmxlIHRyYW5zcG9ydCBwcm90b29j b2wgc2Vzc2lvbuKAnS4gRnJvbSBjb250ZXh0LCBJIGd1ZXNzIOKAnGZsb3figJ0gb3Ig4oCcY29u bmVjdGlvbuKAnSB3b3VsZCBiZSBtb3JlIGFwcHJvcHJpYXRlLg0KDQoNCg0KRExCPiBSVENQIHRl eHQgd2lsbCBiZSBmaXhlZCB3aGVuIG9wZW4gaXNzdWUgaXMgcmVzb2x2ZWQgb24gbGlzdC4NCg0K DQoNCkkgd29uZGVyIGlmIHRoZSBmaXJzdCByZXF1aXJlbWVudCBjYW4gYmUgcGhyYXNlZCBpbiB0 aGUgcG9zaXRpdmU/IEZvciBpbnN0YW5jZToNCg0KDQoNCiogV2l0aGluIGEgc2luZ2xlIFJUUCBz dHJlYW0sIHNob3VsZCB1c2UgYSBzaW5nbGUgUEhCIGFuZCBEU0NQLCBvciBhIHNldCBvZiBQSEJz IGFuZCBEU0NQcyB0aGF0IGRvIG5vdCBhbGxvdyByZW9yZGVyaW5nLCBmb3IgaW5zdGFuY2UgYSBz aW5nbGUgQUYgY2xhc3MuDQoNCg0KDQpETEI+IERvbmUsIEJlbiBhbHNvIG5vdGljZWQgdGhpcy4N Cg0KDQoNCkFsbCBpbiBhbGwsIHRoZSBkb2N1bWVudCdzIHJlY29tbWVuZGF0aW9ucyBhcmUgY2xl YXIgYW5kIHJlYXNvbmFibGUsIGJ1dCB0aGUgZG9jdW1lbnQgY2FuIGJlIGltcHJvdmVkLg0KDQoN Cg0KRExCPiBUaGFuayB5b3UuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K LS0NCg0KU3VydmVpbGxhbmNlIGlzIHBlcnZhc2l2ZS4gR28gRGFyay4NCg== --_000_8D3D17ACE214DC429325B2B98F3AE712077BB42AA0MX15Acorpemcc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFs Ow0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48 Ym9keSBiZ2NvbG9yPXdoaXRlIGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2 IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+SGFyYWxkLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz5UaGFuayB5b3UgZm9yIGNhcmVmdWxseSByZXZpZXdpbmcgdGhp cyBkcmFmdC7CoCBDb21tZW50cy9yZXNwb25zZXMgYXJlIGlubGluZSBhdCBETEImZ3Q7LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz5J4oCZbSBhYm91dCB0byBwb3N0IGEgLTAzIHZlcnNp b24gd2hpY2ggaXMgbm90IGNvbXBsZXRlbHkgZG9uZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPlRoYW5rcyw8YnI+LS1EYXZpZDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0Jz4gRGFydCBbbWFpbHRvOmRhcnQtYm91 bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5IYXJhbGQgQWx2ZXN0cmFuZDxicj48 Yj5TZW50OjwvYj4gRnJpZGF5LCBBdWd1c3QgMjIsIDIwMTQgOTo0NyBBTTxicj48Yj5Ubzo8L2I+ IGRhcnRAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFtEYXJ0XSBIVEEncyBMYXN0IENhbGwg cmV2aWV3IC0gZHJhcnQtZHNjcC1ydHAtMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIHN0eWxlPSdtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41 cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkxhc3QgQ2FsbCByZXZpZXcgLSBk cmF0LWlldGYtZGFydC1kc2NwLXJ0cC0wMjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg c3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAtMDIiPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxMTU1Q0MnPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGFydC1k c2NwLXJ0cC0wMjwvc3Bhbj48c3BhbiBzdHlsZT0ndGV4dC1kZWNvcmF0aW9uOm5vbmUnPiE8bzpw PjwvbzpwPjwvc3Bhbj48L2E+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQnPjxzcGFuIGNsYXNzPU1zb0h5cGVybGluaz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO3RleHQtZGVjb3JhdGlvbjpu b25lJz48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRhcnQt ZHNjcC1ydHAtMDIiPjxzcGFuIHN0eWxlPSd0ZXh0LWRlY29yYXRpb246bm9uZSc+IDwvc3Bhbj48 L2E+PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiInPlN1bW1hcnk6IFRoaXMgZG9jdW1lbnQgaXMgbm90IHJlYWR5IGZvciBJRVRGIExhc3QgQ2Fs bCwgYnV0IGNsb3NlLjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+VGhlIHJlY29tbWVuZGF0aW9ucyBh cmUgcmVhc29uYWJsZSBhbmQgcmVhc29uYWJseSBhcmd1ZWQsIGJ1dCB0aGUgcHJlY2lzaW9uIGFu ZCBzcGVjaWZpY2l0eSBvZiB0aGUgbGFuZ3VhZ2UgbmVlZHMgdG8gYmUgdGlnaHRlbmVkIHVwIGJl Zm9yZSBwdWJsaWNhdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD48L286cD48L3NwYW4+PC9wPjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiJz5UaGUgYmVsb3cgYWRkcmVzc2VzIHNvbWUgc3BlY2lmaWMgY29uY2VybnMuPC9z cGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHAg c3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+U2VjdGlvbiAy PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+bml0OiDi gJxjb21tdW5pY2F0aW9uIGluIHJlYWwtdGltZeKAnSAtJmd0OyDigJxjb21tdW5pY2F0aW9uIGlu IHJlYWwgdGltZeKAnTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+bml0OiBUaGUgY29tcGxleCBleGFt cGxlIG5lZWRzIHRvIG1lbnRpb24gdGhhdCB0aGVyZSBtYXkgYmUgbm9uLW1lZGlhIHN0cmVhbXM7 IHN1Z2dlc3Qg4oCcdGhlcmUgbWF5IGJlIG11bHRpcGxlIG1lZGlhIGFuZCBub24tbWVkaWEgc3Ry ZWFtc+KAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5ETEImZ3Q7IEZpeGVkIGJvdGguPG86cD48 L286cD48L3NwYW4+PC9wPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cCBzdHlsZT0nbWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu NXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4yLjE8L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD48L286 cD48L3NwYW4+PC9wPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cCBzdHlsZT0nbWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuNXB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5SZWZlcmVuY2UgdG8gU1NSQyBmb3Ig cmVmZXJlbmNlIGNsb2NrIGlzIHdyb25nIC0g4oCcYW4gUlRQIHN0cmVhbSBtYXkgY29udGFpbiBt dWx0aXBsZSBzb3VyY2Ugc3RyZWFtcyB0aGF0IHVzZSB0aGUgc2FtZSByZWZlcmVuY2UgY2xvY2sg KFNTUkMp4oCdIC0gdGhpcyBzaG91bGQgYmUg4oCcY2xvY2ssIGlkZW50aWZpZWQgYnkgdGhlIHNh bWUgQ05BTUXigJ0uIFRoZSBTU1JDIGhhcyB0byBiZSBkaWZmZXJlbnQgZm9yIGVhY2ggUlRQIHN0 cmVhbSBpbiBhbiBSVFAgc2Vzc2lvbi4gKFRoZSBuYW1pbmcgY2hvaWNlIGhlcmUgaXMgY29uZnVz aW5n4oCmLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5ETEImZ3Q7IFRoZSB0ZXh0IHJlZmVycyB0 byBhIHNpbmdsZSBSVFAgc3RyZWFtIHRoYXQgY29udGFpbnMgbXVsdGlwbGUgc291cmNlIHN0cmVh bXMsIGJ1dCBvbmx5IG9uZSBTU1JDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkRMQiZndDsgQXJlIHlvdSBzdXJlIHRoYXQg dGhpcyBuZWVkcyB0byBjaGFuZ2UgdG8gQ05BTUUgZnJvbSBTU1JDP8KgIEnigJlkIHByZWZlciBu b3QgdG8gaW50cm9kdWNlIHRoZSBDTkFNRTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0n bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkRMQiZndDsgY29uY2VwdCBpZiBpdOKA mXMgbm90IG5lY2Vzc2FyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiInPlRoZSBzZWN0aW9uIG5lZWRzIHRvIG1lbnRpb24gdGhhdCBSVFAgY2FuIGJlIGNhcnJpZWQg b3ZlciBhIG5vbi1kYXRhZ3JhbSBwcm90b2NvbCBzdWNoIGFzIFRDUCwgYnV0IHRoYXQgdGhpcyBk b2N1bWVudCBkb2VzIG5vdCBzYXkgbW9yZSBhYm91dCB0aGlzIC0ganVzdCB0byBzaG93IHRoYXQg aXRzIG9taXNzaW9uIGlzIGRlbGliZXJhdGUsIG5vdCBhY2NpZGVudGFsLjwvc3Bhbj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIic+KEluIGZhY3QgNS4zIGRpc2N1c3NlcyBUQ1AtZW5jYXBzdWxhdGVkIFJUUC4gU28g aXTigJlzIGFwcHJvcHJpYXRlIHRvIG1lbnRpb24gaXQgaGVyZS4pPG86cD48L286cD48L3NwYW4+ PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+RExCJmd0OyBEb25lLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiInPlNUVU4gaXMgbm90IGFuIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2wsIHNvIHNob3VsZCBi ZSBvbWl0dGVkIGZyb20gdGhlIOKAnGVuY2Fwc3VsYXRlZCB2aWEgU1RVTuKAnSBzZW50ZW5jZS4g VFVSTiBpcy4gU1RVTiBwYWNrZXRzIGFyZSwgaG93ZXZlciwgbXVsdGlwbGV4ZWQgd2l0aCB0aGUg UlRQIHBhY2tldHMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIHN0eWxl PSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+RExCJmd0OyBBZ3JlZSwgc2VlIHRl eHQgaW4gc2VwYXJhdGUgbWVzc2FnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPkFncmVlIHRoYXQgdGhlIFVEUCBzdHJlYW0gaXMgbm90IHVuaWRpcmVjdGlvbmFs LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkRMQiZndDsgQWdyZWUsIGFuZCBwaWNrZWQgdXAgQ29s aW7igJlzIHN1Z2dlc3RlZCBjaGFuZ2UgaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPjIuMjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiInPlNUVU4vVFVSTiBwYXJhZ3JhcGggc2l0cyBvZGRseSBoZXJlLiBJdCBzZWVt cyB0byBiZWxvbmcgb3V0c2lkZSB0aGUg4oCccmVhc29ucyBmb3IgbXVsdGlwbGV4aW5n4oCdIGZs b3cuIFBlcmhhcHMgbW92ZSBpdCB0byB0aGUgYmVnaW5uaW5nIG9mIHRoZSBzZWN0aW9uPzwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+QWdhaW4sIFNUVU4gZGVzY3JpcHRpb24gbmVlZHMgdHVuaW5nOyBT VFVOIGlzIHVzZWQgYWxzbyBmb3IgZW5hYmxpbmcgY29tbXVuaWNhdGlvbiB3aXRob3V0IGEgcmVs YXkgc2VydmVyLCBieSBleGNoYW5naW5nIHB1YmxpY2x5LXZpc2libGUgSVAgYWRkcmVzc2VzIGFu ZCBwb3J0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5ETEImZ3Q7IE9rLCBJIHNlZSDigJxzaXRz IG9kZGx54oCdLsKgIEnigJl2ZSBtb3ZlZCB0aGlzIHRleHQgaW50byBTZWN0aW9uIDIuMSBhbmQg YWRqdXN0ZWQgaXQgLSBzZWUgdGhlIC0wMyBkcmFmdCB3aGVuIGl04oCZcyBwb3N0ZWQuPG86cD48 L286cD48L3NwYW4+PC9wPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cCBzdHlsZT0nbWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu NXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz40Ljwvc3Bhbj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwIHN0eWxlPSdtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPuKAnHJlY2VpdmluZyB0aGUgYXVkaW8g cGFja2V0cyBhaGVhZCBvZiB0aGUgdmlkZW8gaXMgbm90IHVzZWZ1bOKAnSAtJmd0OyDigJxpcyBu b3QgdmVyeSB1c2VmdWzigJ0gLSB0aGUgbmV4dCBzZW50ZW5jZSBnaXZlcyBhIHJlYXNvbiB3aHkg aXQgaXMgc29tZXdoYXQgdXNlZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkRMQiZndDsgQ2hh bmdlZCB0byDigJxzaWduaWZpY2FudGx5IGFoZWFk4oCdIGFuZCBjaGFuZ2VkIG5leHQgc2VudGVu Y2UgdG8gYmUgYWJvdXQgcmVsaWFiaWxpdHkgaW5zdGVhZCBvZiB0aW1pbmcgKGVhcmx5KS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwIHN0eWxlPSdt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjUuMSBEaWZmc2VydiwgUmVv cmRlcmluZyBhbmQgVHJhbnNwb3J0IFByb3RvY29sczwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlRoZSBwYXJhZ3JhcGgg4oCcUmVvcmRlcmluZyBhbHNv IGFmZmVjdHMgb3RoZXIgZm9ybXMgb2YgY29uZ2VzdGlvbiBjb250cm9s4oCdIGlzIHdyb25nLiBU aGUgY29udGVudCBpcyBPSywgYnV0IHRoZSBpbnRybyBpcyBub3QgLSBpdCBpcyB0aGUgZGlmZmVy ZW50aWFsIHRyZWF0bWVudCAoaW5jbHVkaW5nIGRyb3AgcHJvYmFiaWxpdHkpIHRoYXQgY3JlYXRl cyBwcm9ibGVtcyBmb3IgUk1DQVQsIG5vdCAoanVzdCkgdGhlIHJlb3JkZXJpbmcuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+RExCJmd0OyBJIGRvbuKAmXQgdGhpbmsgc28uwqAgSWYgUk1DQVQgY2Fu 4oCZdCBjb3BlIHdpdGggYSB2aWRlbyBzdHJlYW0gdGhhdCB1c2VzIG11bHRpcGxlIFBIQnMgZnJv bSBhbiBBRiBjbGFzcywgc29tZXRoaW5nIGlzIHdyb25nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkRMQiZndDsgSeKAmWxs IHRhZyB0aGlzIGFzIGFuIG9wZW4gaXNzdWUgaW4gdGhlIGRyYWZ0IC0gY291bGQgeW91IHN0YXJ0 IGEgc2VwYXJhdGUgdGhyZWFkIHRoYXQgaW5jbHVkZXMgdGhlIFJNQ0FUIFdHIHRvIHNvcnQgdGhp czxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPkRMQiZndDsgb3V0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIic+RENDUCBpcyBzZW5zaXRpdmUgdG8gZGlmZmVyZW50aWFsIHRyZWF0bWVudCwgc2lu Y2UgaXQgZG9lcyBjb25nZXN0aW9uIGNvbnRyb2wsIHNvIGRlc2NyaXB0aW9uIG9mIGl0IGFzIOKA nHByb2JsZW0gZnJlZeKAnSBpcyB3cm9uZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9 J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5ETEImZ3Q7 IFl1cCwgc2VyaW91cyB0aGlua28gYnkgeW91cnMgdHJ1bHksIHNlZSBvdGhlciBtZXNzYWdlIG9u IHRoYXQgc3BlY2lmaWMgdG9waWMgZm9yIG5ldyB0ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIic+SSB0aGluayB0aGVyZSBhcmUgY29uc2lkZXJhdGlvbnMgY29t aW5nIGZyb20gcmVvcmRlcmluZyAod2hpY2ggYWZmZWN0IHByb3RvY29scyB3aXRoIGltbWVkaWF0 ZSBmZWVkYmFjaywgc3VjaCBhcyBBQ0stYmFzZWQgcHJvdG9jb2xzKSwgYW5kIHRoZXJlIGFyZSBj b25zZGllcmF0aW9ucyBmcm9tIGRpZmVyZW50aWFsIHRyZWF0bWVudCAoZ3Vlc3Npbmcgd3Jvbmcg YWJvdXQgd2hhdOKAmXMgYWZmZWN0ZWQgYnkgYSBxdWV1ZSkuIFRoZSBmb3JtZXIgYXBwbGllcyB0 byBUQ1A7IHRoZSBsYXR0ZXIgYXBwbGllcyB0byBUQ1AsIFNDVFAsIERDQ1AsIGFuZCAocHJvYmFi bHkpIHdoYXRldmVyIFJNQ0FUIGNvbWVzIHRvLiBUaGVzZSB0d28gc2hvdWxkIGJlIHNlcGFyYXRl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz5ETEImZ3Q7IEnigJltIG5vdCBzdXJlIHRoYXQgSSB1 bmRlcnN0YW5kIHdoYXQgeW914oCZcmUgYXNraW5nIGZvciwgYW5kIEnigJltIG5vdCBzdXJlIHdo ZXRoZXIgSSBhZ3JlZS7CoCBJIGJlbGlldmUgdGhhdCBTQ1RQIGlzPG86cD48L286cD48L3NwYW4+ PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+RExCJmd0OyBU Q1AtbGlrZSBpbiBiZWluZyBBQ0stYmFzZWQsIERDQ1AgaXMgY292ZXJlZCBieSB0ZXh0IGluIHRo ZSBvdGhlciBtZXNzYWdlIG9uIHRoYXQgdG9waWMsIGFuZCDigJx3aGF0ZXZlciBSTUNBVCBjb21l cyB0b+KAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPkRMQiZndDsgaXMgc3BlY3VsYXRpdmUgKGFsdGhvdWdoIHRoZSBkcmFm dCBkb2VzIGhhdmUgdGV4dCBvbiBNaWNoYWVsIFdlbHps4oCZcyBjb25jZXJuIGFib3V0IGNvdXBs ZWQgY29uZ2VzdGlvbiBjb250cm9sbGVycyB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPjxwIHN0 eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+RExCJmd0OyBkb27igJl0IHVz ZSBtZWFzdXJlbWVudHMgdG8gZGV0ZWN0IGJvdHRsZW5lY2tzKS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciJz5ETEImZ3Q7IElzIHRoZXJlIHNwZWNpZmljIHRleHQgb24gdGhpcyB0b3BpYyB0aGF0IGNh biBiZSBpZGVudGlmaWVkIGFzIHdyb25nIG9yIG1pc2xlYWRpbmcgYW5kIHByb3Bvc2VkIGFsdGVy bmF0aXZlIHRleHQ/PG86cD48L286cD48L3NwYW4+PC9wPjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz41 LjIgRGlmZlNlcnYsIHJlb3JkZXJpbmcgYW5kIHJlYWwgdGltZSBjb21tdW5pY2F0aW9uPC9zcGFu PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHAgc3R5 bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+VGhlIGxhc3QgcGFy YWdyYXBoIG9mIHRoZSBzZWN0aW9uIGlzIHNvbWV3aGF0IG1pc2xlYWRpbmcgLSBuZXR3b3JrIHBh Y2tldCByZW9yZGVyaW5nIGRvbmUgZm9yICp3aGF0ZXZlciogcmVhc29uIGhhcyBubyB1cHBlciBi b3VuZC4gSWYgdGhlIGF1dGhvcnMgdGhpbmsgdGhhdCBwYWNrZXQgcmVvcmRlcmluZyBpcyBtb3Jl IGxpa2VseSB0byBiZSBwcm9ibGVtYXRpYyB3aXRoIGRpZmZlcmVudCBEU0NQcyB0aGFuIHdpdGgg dGhlIHNhbWUgRFNDUCwgdGhhdOKAmXMgd2hhdCB0aGV5IHNob3VsZCBzYXkuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+RExCJmd0OyBPaywgcGFyYWdyYXBoIG5vdyByZWFkczo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz7CoMKgIE5ldHdvcmsgcGFja2V0IHJlb3JkZXJpbmcgaGFzIG5vIGVmZmVjdGl2 ZSB1cHBlciBib3VuZCwgYW5kIGNhbiBleGNlZWQgdGhlIHNpemUgb2YgYW55IHJlYXNvbmFibGU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTou MDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz7CoMKgIGppdHRlciBidWZmZXIuIEluIHByYWN0aWNlLCB0aGUgc2l6ZSBvZiBqaXR0 ZXIgYnVmZmVycyBmb3IgcmVwbGF5IGlzIGxpbWl0ZWQgYnkgZXh0ZXJuYWwgZmFjdG9yczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPsKgwqAgc3VjaCBhcyB0aGUgYW1vdW50IG9mIHRpbWUgdGhhdCBhIGh1bWFuIGlzIHdpbGxp bmcgdG8gd2FpdCBmb3IgcmVwbGF5IHRvIHN0YXJ0LsKgIFVzZSBvZiBkaWZmZXJlbnQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz7CoMKgIERTQ1BzIHRoYXQgYWxsb3cgcmVvcmRlcmluZyBpcyBtb3JlIGxpa2VseSB0byBjYXVz ZSByZW9yZGVyaW5nIHByb2JsZW1zIHRoYW4gdXNlIG9mIGEgc2luZ2xlIERTQ1A8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7C oMKgIG9yIHNldCBvZiBEU0NQcyB0aGF0IGRvZXMgbm90IGFsbG93IHJlb3JkZXJpbmcuPG86cD48 L286cD48L3NwYW4+PC9wPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cCBzdHlsZT0nbWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu NXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5UaGUgcmVmZXJlbmNlIHRvIFJU Q1AgbXVsdGktc3RyZWFtIG9wdGltaXphdGlvbiBzZWVtcyBjb21wbGV0ZWx5IHdyb25nLiBUaGUg Z3JvdXBpbmcgaW50byBSVENQIHJlcG9ydGluZyBncm91cHMgaXMgYWJvdXQgcmVjZWl2ZXIgU1NS Q3MgdGhhdCBzZWUgdGhlIHNhbWUgc2V0IG9mIHBhY2tldHMsIG5vdCBhYm91dCBncm91cGluZyBy ZXBvcnRzIGFib3V0IGRpZmZlcmVudCBTU1JDIHRvZ2V0aGVyLiAodW5sZXNzIEnigJl2ZSBtaXN1 bmRlcnN0b29kIHNvbWV0aGluZykuIFdoZW4gbm90IHVzaW5nIG11bHRpLXN0cmVhbSBvcHRpbWl6 YXRpb24sIHRoZXNlIFNTUkNzIHNlbmQgZHVwbGljYXRlIHJlcG9ydHMuPG86cD48L286cD48L3Nw YW4+PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+RExCJmd0OyBUaGUgREFSVCBkcmFmdCB0ZXh0IGRvZXMgbm90IG1lbnRpb24gU1NS Q3MsIGFuZCBhcHBlYXJzIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCBTZWN0aW9uIDMgYW5kIHRoZSBm aXJzdCBwYXJhZ3JhcGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciJz5ETEImZ3Q7IG9mIFNlY3Rpb24gMy4xIG9mIGRyYWZ0LWll dGYtYXZ0Y29yZS1ydHAtbXVsdGktc3RyZWFtLW9wdGltaXNhdGlvbi0wMy7CoCBUaGUgcG9pbnQg aXMgdGhhdCBhbnkgdXNlIG9mIGRpZmZlcmVudCBEU0NQczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkRMQiZndDsgZm9yIGRp ZmZlcmVudCBSVFAgc3RyZWFtcyBicmVha3MgdGhlICh0d2ljZS1zdGF0ZWQpIHJlcXVpcmVtZW50 IGluIHRoYXQgQVZUQ09SRSBkcmFmdCBmb3IgYW4gaWRlbnRpY2FsIHZpZXcgb2YgdGhlPG86cD48 L286cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+RExCJmd0OyBuZXR3b3JrIGNvbmRpdGlvbnPigJ0gYWNyb3NzIHRoZSBSVFAgc3RyZWFtcyBp bnZvbHZlZCwgZWFjaCBvZiB3aGljaCBoYXMgaXRzIG93biBTU1JDLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPkRMQiZndDsgSSBkb27igJl0IHRoaW5rIHRoZSBjdXJyZW50IERBUlQgZHJhZnQgdGV4 dCBpcyBhY3R1YWxseSB3cm9uZywgYnV0IEnigJlkIHdlbGNvbWUgZWRpdGluZyBzdWdnZXN0aW9u cyB0aGF0IGltcHJvdmUgY2xhcml0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPjYuIEd1aWRlbGluZXM8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD48L286cD48L3NwYW4+PC9wPjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiJz5UaGUgd29yZCDigJxyZXF1aXJlbWVudHPigJ0gc2VlbXMgYXQgb2Rk cyB3aXRoIHRoZSBoZWFkbGluZSDigJxndWlkZWxpbmVz4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPkRMQiZndDsgRml4ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiJz5UaGUgd29yZCDigJxzZXNzaW9u4oCdIGlzIHVzZWQgc2V2ZXJhbCB0aW1lcyB3aXRob3V0 IGV4cGxhbmF0aW9uIC0g4oCcUlRDUCBzZXNzaW9u4oCdLCDigJxyZWxpYWJsZSB0cmFuc3BvcnQg cHJvdG9vY29sIHNlc3Npb27igJ0uIEZyb20gY29udGV4dCwgSSBndWVzcyDigJxmbG934oCdIG9y IOKAnGNvbm5lY3Rpb27igJ0gd291bGQgYmUgbW9yZSBhcHByb3ByaWF0ZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz5ETEImZ3Q7IFJUQ1AgdGV4dCB3aWxsIGJlIGZpeGVkIHdoZW4gb3BlbiBpc3N1 ZSBpcyByZXNvbHZlZCBvbiBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIic+SSB3b25kZXIgaWYgdGhlIGZpcnN0IHJlcXVpcmVtZW50IGNhbiBiZSBwaHJhc2Vk IGluIHRoZSBwb3NpdGl2ZT8gRm9yIGluc3RhbmNlOjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiogV2l0aGluIGEgc2luZ2xlIFJUUCBzdHJlYW0sIHNo b3VsZCB1c2UgYSBzaW5nbGUgUEhCIGFuZCBEU0NQLCBvciBhIHNldCBvZiBQSEJzIGFuZCBEU0NQ cyB0aGF0IGRvIG5vdCBhbGxvdyByZW9yZGVyaW5nLCBmb3IgaW5zdGFuY2UgYSBzaW5nbGUgQUYg Y2xhc3MuPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+PHByZT5ETEImZ3Q7IERvbmUsIEJlbiBhbHNvIG5vdGljZWQgdGhpcy48bzpwPjwvbzpw PjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPkFsbCBpbiBhbGwsIHRoZSBk b2N1bWVudDxiPidzIHJlY29tbWVuZGF0aW9ucyBhcmUgY2xlYXIgYW5kIHJlYXNvbmFibGUsIGJ1 dCB0aGUgZG9jdW1lbnQgY2FuIGJlIGltcHJvdmVkLjxvOnA+PC9vOnA+PC9iPjwvcHJlPjxwcmU+ PGI+PG86cD4mbmJzcDs8L286cD48L2I+PC9wcmU+PHByZT5ETEImZ3Q7IFRoYW5rIHlvdS48bzpw PjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cCBzdHlsZT0nbWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuNXB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4gPC9zcGFuPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl PjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHBy ZT4tLSA8bzpwPjwvbzpwPjwvcHJlPjxwcmU+U3VydmVpbGxhbmNlIGlzIHBlcnZhc2l2ZS4gR28g RGFyay48bzpwPjwvbzpwPjwvcHJlPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_8D3D17ACE214DC429325B2B98F3AE712077BB42AA0MX15Acorpemcc_-- From nobody Fri Aug 22 18:16:22 2014 Return-Path: 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 9EDDF1A6EF2; Fri, 22 Aug 2014 18:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ikvGH0UP8lJA; Fri, 22 Aug 2014 18:16:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3900C1A0342; Fri, 22 Aug 2014 18:16:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140823011618.31207.73490.idtracker@ietfa.amsl.com> Date: Fri, 22 Aug 2014 18:16:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/I5QVBsb5E7aLhXgn8DlgaT6vvag Cc: dart@ietf.org Subject: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-03.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 01:16:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DiffServ Applied to Real-time Transports Working Group of the IETF. Title : Differentiated Services (DiffServ) and Real-time Communication Authors : David Black Paul Jones Filename : draft-ietf-dart-dscp-rtp-03.txt Pages : 25 Date : 2014-08-22 Abstract: This document describes the interaction between Differentiated Services (DiffServ) network quality of service (QoS) functionality and real-time network communication, including communication based on the Real-time Transport Protocol (RTP). DiffServ is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different DiffServ Code Points (DSCPs). As a result, use of different DSCPs within a single traffic stream may cause transport protocol interactions (e.g., reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This document covers the implications of these DiffServ aspects for real-time network communication, including WebRTC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dart-dscp-rtp-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 22 18:38:23 2014 Return-Path: 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 456C71A0AD0 for ; Fri, 22 Aug 2014 18:38:21 -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 5lvQVlsac8lf for ; Fri, 22 Aug 2014 18:38:18 -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 A661B1A03E7 for ; Fri, 22 Aug 2014 18:38:18 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7N1cG10011034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Aug 2014 21:38:16 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7N1cG10011034 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408757897; bh=bw7swEukVxbpc7r6liUQnAorsvs=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=KZepCW0Ms9S/g7EOfTjiRsBkVhbsJ8bjkjYLjchldRLf2xf3RL4aYIGXA33yCbjWx ixqWyLFQxtqaY9AUHz58K3SbWJKHlIyK01SyXn9a3ZPZPk1i8verXTDsmICIcRjmQN X3vy1d9+zvNc0T1QKXyb8c2D8RCjY0e8Qi5tNvBQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7N1cG10011034 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd03.lss.emc.com (RSA Interceptor) for ; Fri, 22 Aug 2014 21:38:02 -0400 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7N1c4B1019705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Aug 2014 21:38:05 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Fri, 22 Aug 2014 21:38:04 -0400 From: "Black, David" To: "dart@ietf.org" Date: Fri, 22 Aug 2014 21:38:02 -0400 Thread-Topic: draft-ietf-dart-dscp-rtp-03.txt - posted, not done editing, open issues Thread-Index: Ac++cthK978A0c3KTn+t8aSwDYu+Xg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42AA1@MX15A.corp.emc.com> 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: mailusrhubprd54.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/qRKsNxLPyJxyFjJnNIavl7uXfKc Subject: [Dart] draft-ietf-dart-dscp-rtp-03.txt - posted, not done editing, open issues X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 01:38:21 -0000 SSd2ZSBwb3N0ZWQgYSAtMDMgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAtMDMg dG8gY2FwdHVyZSB0aGUNCmVkaXRpbmcgY29tcGxldGVkIHRvZGF5LiAgSGVyZSdzIHdoYXQgSSBi ZWxpZXZlIGFyZSBzdGlsbCBvcGVuIGlzc3Vlcw0Kb3Igd29yayB0byBiZSBkb25lLg0KDQpbQV0g V29yayBpdGVtOiBHb3JyeSBGYWlyaHVyc3QncyBpdGVtICgxKSwgYSBuZXcgU2VjdGlvbiA1LjQg b24gInNpbmdsZQ0KUEhCL0RTQ1AgZm9yIGEgc2luZ2xlIFRDUCBjb25uZWN0aW9uLCBTQ1RQIGFz c29jaWF0aW9uIG9yIERDQ1AgY29ubmVjdGlvbiIgLQ0KSSBuZWVkIHRvIHdyaXRlIHRoaXMgdGV4 dCwgYW5kIHdpbGwgdHJ5IHRvIGRvIHRoYXQgb3ZlciB0aGUgd2Vla2VuZC4NCg0KW0JdIE9wZW4g aXNzdWU6IFBIQnMgYW5kIERTQ1BzIGZvciBSVENQLiAgVGhlIFJUQ1AgZ3VpZGVsaW5lIGJ1bGxl dCBjYW5ub3QNCmJlIHJldmlzZWQgdW50aWwgdGhpcyBvcGVuIGlzc3VlIGlzIHJlc29sdmVkIG9u IHRoZSBsaXN0LiAgU2VlOg0KCWh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9k YXJ0L2N1cnJlbnQvbXNnMDAxNTYuaHRtbA0KDQpbQ10gV29yayBpdGVtOiAgUmVxdWVzdCB0byBC ZW4gQ2FtcGJlbGwgZm9yICJhZGRpdGlvbmFsIHRleHQgb24gY29udGV4dA0KKFdlYlJUQywgY2x1 ZSBhbmQgYnVuZGxlKSBmb3IgdGhlIEludHJvZHVjdGlvbiBhbmQgQWJzdHJhY3QsIHBsdXMgZm9y IGENCmJldHRlciBleGFtcGxlIGluIFNlY3Rpb24gNC4iDQoNCltEXSBPcGVuIGlzc3VlOiBRdWVz dGlvbiB0byBIYXJhbGQgQWx2ZXN0cmFuZCAtIERvZXMgQ05BTUUgbmVlZCB0byBiZSB1c2VkDQpp biBzZWN0aW9uIDIuMiB0ZXh0PyAgSSBob3BlIG5vdC4NCg0KW0VdIE9wZW4gaXNzdWU6IEhhcmFs ZCBBbHZlc3RyYW5kJ3MgY29uY2VybnMgYWJvdXQgImRpZmZlcmVudGlhbCB0cmVhdG1lbnQiDQp3 cnQgU2VjdGlvbiA1LjEgLiAgSSBkb24ndCBjb21wbGV0ZWx5IHVuZGVyc3RhbmQgdGhlc2UgY29u Y2VybnMsIGFuZCBzdXNwZWN0DQp0aGF0IHRoZXkgbWF5IHJlcXVpcmUgYW4gZW1haWwgZGlzY3Vz c2lvbiBhY3Jvc3MgdGhlIERBUlQgYW5kIFJNQ0FUIFdHcw0KdG8gc29ydCB0aHJvdWdoLg0KDQpb Rl0gT3BlbiBpc3N1ZTogSGFyYWxkIEFsdmVzdHJhbmQncyBjb25jZXJucyBhYm91dCB0aGUgUlRD UCBtdWx0aS1zdHJlYW0NCm9wdGltaXphdGlvbiB0ZXh0IGluIHNlY3Rpb24gNS4yIC4gIEkgZG9u J3QgdGhpbmsgdGhlcmUncyBhIHByb2JsZW0gaGVyZSwNCmJ1dCBJJ20gbm90IGFuIGV4cGVydCBv biB0aGUgUlRDUCB0ZWNobm9sb2d5IGludm9sdmVkLCBhbmQgSGFyYWxkIG1heSBub3QNCmFncmVl LiAgVGhpcyBpcyBhIGRpZmZlcmVudCBSVENQIGlzc3VlIHRoYW4gW0JdLg0KDQpGb3IgW0RdLCBb RV0gYW5kIFtGXSwgc2VlIG15IHJlY2VudCByZXNwb25zZSB0byBIYXJhbGQ6DQoJaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2RhcnQvY3VycmVudC9tc2cwMDE2NC5odG1sDQoN CkkgYXBwcmVjaWF0ZSBIYXJhbGQncyBpbmR1bGdlbmNlIG9mIHRoZSBmYWN0IHRoYXQgSSBzZW50 IHRoYXQgcmVzcG9uc2UNCmF0IGFuIHVucmVhc29uYWJsZSBob3VyIGZvciBoaW0gYW5kIHRoZW4g aW1tZWRpYXRlbHkgdGFnZ2VkIGhpbSB3aXRoDQpyZXNwb25zaWJpbGl0eSBmb3IgaGFsZiB0aGUg aXRlbXMgYWJvdmUuICBJJ20gc3VyZSBoZSdsbCBmaW5kIGEgd2F5IHRvDQoicmV0dXJuIHRoZSBm YXZvciIgOy0pLg0KDQpUaGFua3MsDQotLURhdmlkDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIEF1Z3VzdCAyMiwgMjAxNCA5OjE2IFBNDQpU bzogQmxhY2ssIERhdmlkOyBQYXVsIEpvbmVzOyBCbGFjaywgRGF2aWQ7IFBhdWwgSm9uZXMNClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kYXJ0LWRzY3At cnRwLTAzLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWRhcnQtZHNj cC1ydHAtMDMudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERhdmlkIEJs YWNrIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1p ZXRmLWRhcnQtZHNjcC1ydHANClJldmlzaW9uOgkwMw0KVGl0bGU6CQlEaWZmZXJlbnRpYXRlZCBT ZXJ2aWNlcyAoRGlmZlNlcnYpIGFuZCBSZWFsLXRpbWUgQ29tbXVuaWNhdGlvbg0KRG9jdW1lbnQg ZGF0ZToJMjAxNC0wOC0yMg0KR3JvdXA6CQlkYXJ0DQpQYWdlczoJCTI1DQpVUkw6ICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1kYXJ0LWRz Y3AtcnRwLTAzLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cC8NCkh0bWxpemVkOiAgICAgICBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAtMDMNCkRpZmY6ICAg ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRhcnQt ZHNjcC1ydHAtMDMNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUg aW50ZXJhY3Rpb24gYmV0d2VlbiBEaWZmZXJlbnRpYXRlZA0KICAgU2VydmljZXMgKERpZmZTZXJ2 KSBuZXR3b3JrIHF1YWxpdHkgb2Ygc2VydmljZSAoUW9TKSBmdW5jdGlvbmFsaXR5DQogICBhbmQg cmVhbC10aW1lIG5ldHdvcmsgY29tbXVuaWNhdGlvbiwgaW5jbHVkaW5nIGNvbW11bmljYXRpb24g YmFzZWQgb24NCiAgIHRoZSBSZWFsLXRpbWUgVHJhbnNwb3J0IFByb3RvY29sIChSVFApLiAgRGlm ZlNlcnYgaXMgYmFzZWQgb24gbmV0d29yaw0KICAgbm9kZXMgYXBwbHlpbmcgZGlmZmVyZW50IGZv cndhcmRpbmcgdHJlYXRtZW50cyB0byBwYWNrZXRzIHdob3NlIElQDQogICBoZWFkZXJzIGFyZSBt YXJrZWQgd2l0aCBkaWZmZXJlbnQgRGlmZlNlcnYgQ29kZSBQb2ludHMgKERTQ1BzKS4gIEFzIGEN CiAgIHJlc3VsdCwgdXNlIG9mIGRpZmZlcmVudCBEU0NQcyB3aXRoaW4gYSBzaW5nbGUgdHJhZmZp YyBzdHJlYW0gbWF5DQogICBjYXVzZSB0cmFuc3BvcnQgcHJvdG9jb2wgaW50ZXJhY3Rpb25zIChl LmcuLCByZW9yZGVyaW5nKS4gIEluDQogICBhZGRpdGlvbiwgRFNDUCBtYXJraW5ncyBtYXkgYmUg Y2hhbmdlZCBvciByZW1vdmVkIGJldHdlZW4gdGhlIHRyYWZmaWMNCiAgIHNvdXJjZSBhbmQgZGVz dGluYXRpb24uICBUaGlzIGRvY3VtZW50IGNvdmVycyB0aGUgaW1wbGljYXRpb25zIG9mDQogICB0 aGVzZSBEaWZmU2VydiBhc3BlY3RzIGZvciByZWFsLXRpbWUgbmV0d29yayBjb21tdW5pY2F0aW9u LCBpbmNsdWRpbmcNCiAgIFdlYlJUQy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== From nobody Sat Aug 23 15:50:58 2014 Return-Path: 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 6E4D31A0B80 for ; Sat, 23 Aug 2014 15:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 tLEjYGuTG6-v for ; Sat, 23 Aug 2014 15:50:54 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3691A0B7E for ; Sat, 23 Aug 2014 15:50:54 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7NMojLN074850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Aug 2014 17:50:47 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BB42A9A@MX15A.corp.emc.com> Date: Sat, 23 Aug 2014 17:50:43 -0500 X-Mao-Original-Outgoing-Id: 430527043.700086-61f462b942e4e5092cd442633bcbcce9 Content-Transfer-Encoding: quoted-printable Message-Id: <323887A6-A313-495E-AFFD-B921D3628F72@nostrum.com> References: <62D70F5C-C6CF-48C7-AE9F-55B17172555D@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BB42A9A@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/g4TfWB29-jaIcPIPbpT3rqHlUF0 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" Subject: Re: [Dart] WGLC Comments on draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 22:50:57 -0000 Hi, comments inline. I deleted sections that do not need to seem further = comment (or where the comment would have been "okay"). On Aug 22, 2014, at 7:03 PM, Black, David wrote: [...] >=20 >> -- Abstract (and intro) >>=20 >> It's probably worth mentioning that, other than mixing RTP/RTCP, RTP >> multiplexing is a relatively new thing. It's needed by new work such = as WebRTC >> and clue, and it is enabled by bundle. The point being, this wasn't = something >> we really needed to worry about until now. >=20 > Could you suggest text for the Introduction section, along with any = additional references? Okay, how about something like the following (perhaps inserted after = "... including communication based on the Real-time Transport Protocol = (RTP)") "Historically, distinct RTP streams have been sent over different = transport level flows, sometimes multiplexed with RTCP. But recently = WebRTC applications, as well as some conferencing applications, have = begun using the Session Description Protocol (SDP) [RFC4566] bundle = negotiation mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] to send = multiple streams, potentially needing different QoS treatments, using = the same IP 5-tuple." [...] >>=20 >> -- section 4: >>=20 >> It might be nice to have a more WebRTC-ish example. For example an = audio >> stream, video stream, and a data channel carrying something like a = shared >> white board or game. >=20 > Sure, please send text. >=20 Okay, how about something like the following, added to the end of = section 4: "A WebRTC application may carry one or more RTP streams, as discussed = above. In addition, it might carry an SCTP data channel. The treatment = of the data channel would depend on the nature of the application. For = example, messaging applications, shared white board, or guided browsing = applications might be best effort, while a latency-sensitive game = application might require a higher priority PHB. " >> -- section 6, last bullet: >>=20 >> Is there a such thing as "less than best effort traffic" where "best = effort" >> treatments would be unacceptable? >=20 > I can come up with possible examples - background bulk transfer of = something > large that should not interfere with foreground WebRTC data that is = being > carried as best-effort. >>=20 >> Actually, it's not clear to me from this paragraph if CS1 is ever = appropriate, >> at least from the application endpoint perspective, as it seem to = give >> completely unpredictable results. >=20 > That was intended - would you like to see stronger language? >=20 No, if that is the intent, I am okay with the existing language. [...] From nobody Sat Aug 23 15:52:40 2014 Return-Path: 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 6F47C1A0B80 for ; Sat, 23 Aug 2014 15:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 cTSomIiGuNYt for ; Sat, 23 Aug 2014 15:52:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA171A0B7E for ; Sat, 23 Aug 2014 15:52:37 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7NMqWHc074983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Aug 2014 17:52:33 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <323887A6-A313-495E-AFFD-B921D3628F72@nostrum.com> Date: Sat, 23 Aug 2014 17:52:31 -0500 X-Mao-Original-Outgoing-Id: 430527150.998677-8372053469d03ece27789750b64205f5 Content-Transfer-Encoding: quoted-printable Message-Id: References: <62D70F5C-C6CF-48C7-AE9F-55B17172555D@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BB42A9A@MX15A.corp.emc.com> <323887A6-A313-495E-AFFD-B921D3628F72@nostrum.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/C3ut32bikzpowXgWJuPxbNYObT0 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" Subject: Re: [Dart] WGLC Comments on draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 22:52:38 -0000 On Aug 23, 2014, at 5:50 PM, Ben Campbell wrote: >>>=20 >>> -- section 4: >>>=20 >>> It might be nice to have a more WebRTC-ish example. For example an = audio >>> stream, video stream, and a data channel carrying something like a = shared >>> white board or game. >>=20 >> Sure, please send text. >>=20 >=20 > Okay, how about something like the following, added to the end of = section 4: >=20 > "A WebRTC application may carry one or more RTP streams, as discussed = above. In addition, it might carry an SCTP data channel. The treatment = of the data channel would depend on the nature of the application. For = example, messaging applications, shared white board, or guided browsing = applications might be best effort, while a latency-sensitive game = application might require a higher priority PHB. " Oops, I meant to add draft-ietf-rtcweb-data-channel-11 as a reference = for WebRTC data channels.= From nobody Sun Aug 24 22:00:22 2014 Return-Path: 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 8B9071A8A0C for ; Sun, 24 Aug 2014 22:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.668] 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 j_XWWgZkZlyo for ; Sun, 24 Aug 2014 22:00:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B661A8A09 for ; Sun, 24 Aug 2014 22:00:17 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7P50Fn9037421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 25 Aug 2014 00:00:17 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: Ben Campbell Content-Type: text/plain; charset=us-ascii X-Mao-Original-Outgoing-Id: 430635615.389255-6e469708cff1a1c1abeb25760d4f4575 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Message-Id: <442BA084-2172-4251-BBD6-EF8280055854@nostrum.com> Date: Mon, 25 Aug 2014 00:00:15 -0500 To: dart@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/yyQjwRJmiYGU5nj2Ccc-bfhfv-8 Subject: [Dart] Open Issue: Guidance for RTCP X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 05:00:19 -0000 (as chair) We have an open issue (Designated issue [B] by David) about what = guidance to give about RTCP in draft-ietf-dart-dscp-rtp. We need to = close this in order to progress the draft--meaning we need to do so = ASAP. Please look at the the following quoted text for background, and offer = an opinion: > (2) PHBs and DSCPs for RTCP. >=20 > 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. =20= >=20 > Colin (from WGLC comments): >=20 > > 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. >=20 > Paul (from shortly after the Toronto meeting: >=20 > > 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. :-) > >=20 > > 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. > > =20 > > 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. >=20 >=20 From nobody Mon Aug 25 00:36:18 2014 Return-Path: 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 68B7B1A8AC6; Mon, 25 Aug 2014 00:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 FrMLUx5sDcUg; Mon, 25 Aug 2014 00:36:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4621A8ABF; Mon, 25 Aug 2014 00:36:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140825073613.6390.35581.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 00:36:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Lny3OhQo21BU_Zo22DP4etQtY88 Cc: dart@ietf.org Subject: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-04.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 07:36:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DiffServ Applied to Real-time Transports Working Group of the IETF. Title : Differentiated Services (DiffServ) and Real-time CommunicHtion Authors : David Black Paul Jones Filename : draft-ietf-dart-dscp-rtp-04.txt Pages : 26 Date : 2014-08-25 Abstract: This document describes the interaction between Differentiated Services (DiffServ) network quality of service (QoS) functionality and real-time network communication, including communication based on the Real-time Transport Protocol (RTP). DiffServ is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different DiffServ Code Points (DSCPs). WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirments using the same network 5-tuple. Use of different DSCPs to obtain different QoS treatments within a single network 5-tuple, the results (e.g., reordering) may cause transport protocol interactions, particularly with congestion control functionality. In addition, DSCP markings may be changed or removed between the traffic source and destination. This document covers the implications of these DiffServ aspects for real-time network communication, including WebRTC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dart-dscp-rtp-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 25 00:47:58 2014 Return-Path: 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 368CD1A8ABF for ; Mon, 25 Aug 2014 00:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_OFF=2.3, 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 T4OccFfuJ1fO for ; Mon, 25 Aug 2014 00:47:54 -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 C75331A8AA7 for ; Mon, 25 Aug 2014 00:47:53 -0700 (PDT) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7P7lqCn022515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Aug 2014 03:47:52 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s7P7lqCn022515 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408952872; bh=+mSj/b7Pq98TDbb0JhNlZQNRw8A=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=fnT18UgVVm1grDAOooD3eLoy9fDN8v2doOnS478s8Hwc9MjfNduWZHy+VjMw4AWIt i/e9jXJE+bvr5S2FxCYoZZpOztfWNSC+sQcbu8EbWC15xs8qVNkOtjjM9uOW/BiZPj Q5kwh9+uTyUhSkQTp8rrxj1MRrgKiIPyjM6ObxI0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s7P7lqCn022515 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd56.lss.emc.com (RSA Interceptor) for ; Mon, 25 Aug 2014 03:47:38 -0400 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7P7liDw010085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Aug 2014 03:47:44 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub14.corp.emc.com ([128.222.70.235]) with mapi; Mon, 25 Aug 2014 03:47:43 -0400 From: "Black, David" To: "dart@ietf.org" Date: Mon, 25 Aug 2014 03:47:42 -0400 Thread-Topic: New Version Notification for draft-ietf-dart-dscp-rtp-04.txt Thread-Index: Ac/AN0OobwZ7vxMbTPC/QRf9Zy1kKQAABadw Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42B36@MX15A.corp.emc.com> References: <20140825073613.6390.75863.idtracker@ietfa.amsl.com> In-Reply-To: <20140825073613.6390.75863.idtracker@ietfa.amsl.com> 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: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/i1_MiWbqwTe7hLD9WQhofslj5mU Subject: [Dart] FW: New Version Notification for draft-ietf-dart-dscp-rtp-04.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 07:47:56 -0000 UHJvZ3Jlc3MgaW4gdGhpcyB2ZXJzaW9uOg0KDQo+IFtBXSBXb3JrIGl0ZW06IEdvcnJ5IEZhaXJo dXJzdCdzIGl0ZW0gKDEpLCBhIG5ldyBTZWN0aW9uIDUuNCBvbiAic2luZ2xlDQo+IFBIQi9EU0NQ IGZvciBhIHNpbmdsZSBUQ1AgY29ubmVjdGlvbiwgU0NUUCBhc3NvY2lhdGlvbiBvciBEQ0NQIGNv bm5lY3Rpb24iIC0NCj4gSSBuZWVkIHRvIHdyaXRlIHRoaXMgdGV4dCwgYW5kIHdpbGwgdHJ5IHRv IGRvIHRoYXQgb3ZlciB0aGUgd2Vla2VuZC4NCg0KSSB3b3VuZCB1cCBhZGRpbmcgdGhpcyB0ZXh0 IHRvIFNlY3Rpb24gNS4xLCBhbmQgc2xpbW1lZCBkb3duIHRoZSBjb3JyZXNwb25kaW5nDQpndWlk ZWxpbmUgaW4gU2VjdGlvbiA2LiAgSSBob3BlIHRoaXMgc3VmZmljZXMgLSBHb3JyeSBzaG91bGQg Y2hlY2sgdGhlIHRleHQNCmluIHRoZSAtMDQuDQoNCj4gW0JdIE9wZW4gaXNzdWU6IFBIQnMgYW5k IERTQ1BzIGZvciBSVENQLiAgVGhlIFJUQ1AgZ3VpZGVsaW5lIGJ1bGxldCBjYW5ub3QNCj4gYmUg cmV2aXNlZCB1bnRpbCB0aGlzIG9wZW4gaXNzdWUgaXMgcmVzb2x2ZWQgb24gdGhlIGxpc3QuICBT ZWU6DQoJaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2RhcnQvY3VycmVudC9t c2cwMDE1Ni5odG1sDQoNClN0aWxsIG9wZW4sIHNlZSBCZW4ncyByZWNlbnQgbWVzc2FnZS4NCg0K PiBbQ10gV29yayBpdGVtOiAgUmVxdWVzdCB0byBCZW4gQ2FtcGJlbGwgZm9yICJhZGRpdGlvbmFs IHRleHQgb24gY29udGV4dA0KPiAoV2ViUlRDLCBjbHVlIGFuZCBidW5kbGUpIGZvciB0aGUgSW50 cm9kdWN0aW9uIGFuZCBBYnN0cmFjdCwgcGx1cyBmb3IgYQ0KPiBiZXR0ZXIgZXhhbXBsZSBpbiBT ZWN0aW9uIDQuIg0KDQpDbG9zZWQgYnkgYWRkaXRpb25hbCB0ZXh0IGluIC0wNC4gIEJlbiBzaG91 bGQgZG91YmxlLWNoZWNrIHRoYXQgdGhlIHJlc3VsdA0KaXMgYWNjZXB0YWJsZS4NCg0KPiBbRF0g T3BlbiBpc3N1ZTogUXVlc3Rpb24gdG8gSGFyYWxkIEFsdmVzdHJhbmQgLSBEb2VzIENOQU1FIG5l ZWQgdG8gYmUgdXNlZA0KPiBpbiBzZWN0aW9uIDIuMiB0ZXh0PyAgSSBob3BlIG5vdC4NCg0KQ2xv c2VkIC0gdGhpcyB3YXMgYWN0dWFsbHkgaW4gMi4xLCBhbmQgYmFzZWQgb24gcHJpdmF0ZSBkaXNj dXNzaW9uIHcvSGFyYWxkLA0KdGhpcyBpc3N1ZSBoYXMgbm93IGJlZW4gY2xvc2VkIGJ5IGEgc21h bGwgZWRpdCBpbiAtMDQgdG8gcmVtb3ZlIGEgcHJvYmxlbWF0aWMNCmFuZCB1bm5lY2Vzc2FyeSB1 c2Ugb2YgU1NSQzoNCg0KT0xEDQogICBJbiBhZGRpdGlvbiwgYW4gUlRQIHN0cmVhbQ0KICAgbWF5 IGNvbnRhaW4gbXVsdGlwbGUgc291cmNlIHN0cmVhbXMgdGhhdCB1c2UgdGhlIHNhbWUgcmVmZXJl bmNlIGNsb2NrDQogICAoU1NSQyksIGUuZy4sIGNvbXBvbmVudHMgb3IgcHJvZ3JhbXMgaW4gYW4g TVBFRyBUcmFuc3BvcnQgU3RyZWFtDQogICBbSC4yMjIuMF0uDQpORVcNCiAgIEluIGFkZGl0aW9u LCBhbiBSVFAgc3RyZWFtDQogICBtYXkgY29udGFpbiBtdWx0aXBsZSBzb3VyY2Ugc3RyZWFtcywg ZS5nLiwgY29tcG9uZW50cyBvciBwcm9ncmFtcyBpbg0KICAgYW4gTVBFRyBUcmFuc3BvcnQgU3Ry ZWFtIFtILjIyMi4wXS4NCg0KPiBbRV0gT3BlbiBpc3N1ZTogSGFyYWxkIEFsdmVzdHJhbmQncyBj b25jZXJucyBhYm91dCAiZGlmZmVyZW50aWFsIHRyZWF0bWVudCINCj4gd3J0IFNlY3Rpb24gNS4x IC4gIEkgZG9uJ3QgY29tcGxldGVseSB1bmRlcnN0YW5kIHRoZXNlIGNvbmNlcm5zLCBhbmQgc3Vz cGVjdA0KPiB0aGF0IHRoZXkgbWF5IHJlcXVpcmUgYW4gZW1haWwgZGlzY3Vzc2lvbiBhY3Jvc3Mg dGhlIERBUlQgYW5kIFJNQ0FUIFdHcw0KPiB0byBzb3J0IHRocm91Z2guDQoNClN0aWxsIG9wZW4g LSBIYXJhbGQgc2hvdWxkIHBvc3Qgc3BlY2lmaWMgcmVxdWVzdHMgZm9yIHRleHQgY2hhbmdlcyB0 byB0aGUNCmxpc3QuDQoNCj4gW0ZdIE9wZW4gaXNzdWU6IEhhcmFsZCBBbHZlc3RyYW5kJ3MgY29u Y2VybnMgYWJvdXQgdGhlIFJUQ1AgbXVsdGktc3RyZWFtDQo+IG9wdGltaXphdGlvbiB0ZXh0IGlu IHNlY3Rpb24gNS4yIC4gIEkgZG9uJ3QgdGhpbmsgdGhlcmUncyBhIHByb2JsZW0gaGVyZSwNCj4g YnV0IEknbSBub3QgYW4gZXhwZXJ0IG9uIHRoZSBSVENQIHRlY2hub2xvZ3kgaW52b2x2ZWQsIGFu ZCBIYXJhbGQgbWF5IG5vdA0KPiBhZ3JlZS4gIFRoaXMgaXMgYSBkaWZmZXJlbnQgUlRDUCBpc3N1 ZSB0aGFuIFtCXS4NCg0KQnV0LCBiYXNlZCBvbiBwcml2YXRlIGRpc2N1c3Npb24gdy9IYXJhbGQs IFtGXSBkZXBlbmRzIG9uIFtCXSwgYW5kIHJlc29sdXRpb24NCm9mIFtCXSBpcyBsaWtlbHkgdG8g bGVhZCB0byByZXNvbHV0aW9uIG9mIFtGXS4gIEJlbidzIHN0YXJ0ZWQgYSB0aHJlYWQgb24NCltC XSwgc28gSSdsbCBjb21tZW50IGZ1cnRoZXIgdGhlcmUuDQoNClRoYW5rcywNCi0tRGF2aWQNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEF1Z3Vz dCAyNSwgMjAxNCAzOjM2IEFNDQpUbzogQmxhY2ssIERhdmlkOyBQYXVsIEpvbmVzOyBCbGFjaywg RGF2aWQ7IFBhdWwgSm9uZXMNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtaWV0Zi1kYXJ0LWRzY3AtcnRwLTA0LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAtMDQudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IERhdmlkIEJsYWNrIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRv cnkuDQoNCk5hbWU6CQlkcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHANClJldmlzaW9uOgkwNA0KVGl0 bGU6CQlEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyAoRGlmZlNlcnYpIGFuZCBSZWFsLXRpbWUgQ29t bXVuaWNIdGlvbg0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wOC0yNQ0KR3JvdXA6CQlkYXJ0DQpQYWdl czoJCTI2DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaWV0Zi1kYXJ0LWRzY3AtcnRwLTA0LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cC8NCkh0 bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRhcnQt ZHNjcC1ydHAtMDQNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAtMDQNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiBEaWZmZXJlbnRpYXRlZA0K ICAgU2VydmljZXMgKERpZmZTZXJ2KSBuZXR3b3JrIHF1YWxpdHkgb2Ygc2VydmljZSAoUW9TKSBm dW5jdGlvbmFsaXR5DQogICBhbmQgcmVhbC10aW1lIG5ldHdvcmsgY29tbXVuaWNhdGlvbiwgaW5j bHVkaW5nIGNvbW11bmljYXRpb24gYmFzZWQgb24NCiAgIHRoZSBSZWFsLXRpbWUgVHJhbnNwb3J0 IFByb3RvY29sIChSVFApLiAgRGlmZlNlcnYgaXMgYmFzZWQgb24gbmV0d29yaw0KICAgbm9kZXMg YXBwbHlpbmcgZGlmZmVyZW50IGZvcndhcmRpbmcgdHJlYXRtZW50cyB0byBwYWNrZXRzIHdob3Nl IElQDQogICBoZWFkZXJzIGFyZSBtYXJrZWQgd2l0aCBkaWZmZXJlbnQgRGlmZlNlcnYgQ29kZSBQ b2ludHMgKERTQ1BzKS4NCiAgIFdlYlJUQyBhcHBsaWNhdGlvbnMsIGFzIHdlbGwgYXMgc29tZSBj b25mZXJlbmNpbmcgYXBwbGljYXRpb25zLCBoYXZlDQogICBiZWd1biB1c2luZyB0aGUgU2Vzc2lv biBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKSBidW5kbGUgbmVnb3RpYXRpb24NCiAgIG1lY2hh bmlzbSB0byBzZW5kIG11bHRpcGxlIHRyYWZmaWMgc3RyZWFtcyB3aXRoIGRpZmZlcmVudCBRb1MN CiAgIHJlcXVpcm1lbnRzIHVzaW5nIHRoZSBzYW1lIG5ldHdvcmsgNS10dXBsZS4gIFVzZSBvZiBk aWZmZXJlbnQgRFNDUHMNCiAgIHRvIG9idGFpbiBkaWZmZXJlbnQgUW9TIHRyZWF0bWVudHMgd2l0 aGluIGEgc2luZ2xlIG5ldHdvcmsgNS10dXBsZSwNCiAgIHRoZSByZXN1bHRzIChlLmcuLCByZW9y ZGVyaW5nKSBtYXkgY2F1c2UgdHJhbnNwb3J0IHByb3RvY29sDQogICBpbnRlcmFjdGlvbnMsIHBh cnRpY3VsYXJseSB3aXRoIGNvbmdlc3Rpb24gY29udHJvbCBmdW5jdGlvbmFsaXR5LiAgSW4NCiAg IGFkZGl0aW9uLCBEU0NQIG1hcmtpbmdzIG1heSBiZSBjaGFuZ2VkIG9yIHJlbW92ZWQgYmV0d2Vl biB0aGUgdHJhZmZpYw0KICAgc291cmNlIGFuZCBkZXN0aW5hdGlvbi4gIFRoaXMgZG9jdW1lbnQg Y292ZXJzIHRoZSBpbXBsaWNhdGlvbnMgb2YNCiAgIHRoZXNlIERpZmZTZXJ2IGFzcGVjdHMgZm9y IHJlYWwtdGltZSBuZXR3b3JrIGNvbW11bmljYXRpb24sIGluY2x1ZGluZw0KICAgV2ViUlRDLg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Aug 25 00:57:51 2014 Return-Path: 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 E917C1A8AE3 for ; Mon, 25 Aug 2014 00:57:49 -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 wx0waMmCe1sm for ; Mon, 25 Aug 2014 00:57:48 -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 0FCF51A8AE2 for ; Mon, 25 Aug 2014 00:57:47 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7P7vk15017302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2014 03:57:46 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s7P7vk15017302 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408953466; bh=NdvMhCF8GPO3epMmw7TjCwqdswo=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=d0Az4SV7x5aiepISNo9DQrmICYhUw0gqKtrqagfAi/CHGe0RAQv8Yi65NKkCJLta5 tjz+tmR8+Y8bBYvZIRpbsw51Rcz9rCJ8xK7t7rZbSdfAvCGZX71iBPA2DGdFqXjV4u DiItoBWkX2/BafaD35x/FwgqcXwRXsm1vpVOR2qk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s7P7vk15017302 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 25 Aug 2014 03:57:22 -0400 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7P7vQGD023692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 03:57:27 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Mon, 25 Aug 2014 03:57:26 -0400 From: "Black, David" To: Ben Campbell , "dart@ietf.org" Date: Mon, 25 Aug 2014 03:57:24 -0400 Thread-Topic: [Dart] Open Issue: Guidance for RTCP Thread-Index: Ac/AIYDACC+DFcQzTqCt3r0ARyMWEgAF21rQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42B3A@MX15A.corp.emc.com> References: <442BA084-2172-4251-BBD6-EF8280055854@nostrum.com> In-Reply-To: <442BA084-2172-4251-BBD6-EF8280055854@nostrum.com> 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: DLM_1, public, GIS Solicitation Archived-At: http://mailarchive.ietf.org/arch/msg/dart/9YxCa5DbjauyxODzIYsqdHox7i8 Subject: Re: [Dart] Open Issue: Guidance for RTCP X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 07:57:50 -0000 (as editor) I believe the core of this issue is the role of RTCP in providing RTT estimates. This is the core of open issue [B] and resolving it is likely to resolve much of open issue [F]. I believe the key question is: Is the role of RTCP in providing RTCP estimates important enough to serve as the primary basis for providing guidance on DSCP usage w/RTCP? Here's a summary of the "yes it is" viewpoint (from Colin Perkins): 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. And a summary of the "no it isn't" viewpoint (from Paul Jones): 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. Thanks, --David (as editor) > -----Original Message----- > From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Monday, August 25, 2014 1:00 AM > To: dart@ietf.org > Subject: [Dart] Open Issue: Guidance for RTCP >=20 > (as chair) >=20 > We have an open issue (Designated issue [B] by David) about what guidance= to > give about RTCP in draft-ietf-dart-dscp-rtp. We need to close this in ord= er to > progress the draft--meaning we need to do so ASAP. >=20 > Please look at the the following quoted text for background, and offer an > opinion: >=20 >=20 > > (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 se= nse, > but > > > it's important to note that one role of RTCP is to provide an estimat= e of > the > > > round-trip time seen by the media, so the PHB/DSCP will have to be ch= osen > 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. So= me > > > notes I received on this topic suggested that it was proposed that RT= CP > > > 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 direc= tion. > > > > > > Further, an RTCP packet might provide information related to several > different > > > RTP packets. I certainly would not want to see one RTCP packet per R= TP > packet. > > > > >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Mon Aug 25 03:09:27 2014 Return-Path: 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 261111A8BC1 for ; Mon, 25 Aug 2014 03:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 LmG17LCCkyIy for ; Mon, 25 Aug 2014 03:09:02 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB371A8BB3 for ; Mon, 25 Aug 2014 03:09:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 6AFEA7C3F65 for ; Mon, 25 Aug 2014 12:08:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIS8L-OW440D for ; Mon, 25 Aug 2014 12:08:54 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:6dc8:104c:7418:7e33] (unknown [IPv6:2001:470:de0a:27:6dc8:104c:7418:7e33]) by mork.alvestrand.no (Postfix) with ESMTPSA id D62D37C3F61 for ; Mon, 25 Aug 2014 12:08:53 +0200 (CEST) Message-ID: <53FB0B35.6060101@alvestrand.no> Date: Mon, 25 Aug 2014 12:08:53 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: dart@ietf.org References: <442BA084-2172-4251-BBD6-EF8280055854@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BB42B3A@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BB42B3A@MX15A.corp.emc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/5jJi6_Ptz3bog0BB5MbkmrCXhL0 Subject: Re: [Dart] Open Issue: Guidance for RTCP X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 10:09:12 -0000 On 08/25/2014 09:57 AM, Black, David wrote: > (as editor) > > I believe the core of this issue is the role of RTCP in providing RTT > estimates. This is the core of open issue [B] and resolving it is > likely to resolve much of open issue [F]. I think we're just scratching at a deeper issue here: What is the role of the RTT estimate, and is RTT what we're looking for? In ack-based congestion control, RTT estimates are used to determine when we should say "we have not seen the ACK we expected" - which indicates either packet loss or increased congestion, either on the forward or the reverse path - the algorithm does not care which. The signal is only useful for end-of-packet-train packet loss (because otherwise there will be later packets leading to SACK indications of lost packets before the RTT timer runs out), so the exact value doesn't really matter - only that the false positive rate isn't too high. In delay-based, sender-side-only congestion control, however, RTT has to be used as a stand-in for the sender->receiver transit time (because we have nothing else). So any variation in return-path RTT is going to be interpreted as congestion change on the forward path - which means wrong decisions. My conclusions are two: - If delay-based senders-side-only is used, what matters is that the feedback signal gets there with as little delay variation as possible. The highest precedence available should be used. - Delay-based schemes need to have the timing done at receiver. RTT is just too sensitive to errors. The last argument belongs in RMCAT, not here. I'll leave the first argument for your consideration. > > I believe the key question is: > > Is the role of RTCP in providing RTCP estimates important enough > to serve as the primary basis for providing guidance on DSCP usage > w/RTCP? > > Here's a summary of the "yes it is" viewpoint (from Colin Perkins): > > 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. To which my comment is "media has no round trip time". Media goes one way. > > And a summary of the "no it isn't" viewpoint (from Paul Jones): > > 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. > > Thanks, > --David (as editor) > >> -----Original Message----- >> From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Ben Campbell >> Sent: Monday, August 25, 2014 1:00 AM >> To: dart@ietf.org >> Subject: [Dart] Open Issue: Guidance for RTCP >> >> (as chair) >> >> We have an open issue (Designated issue [B] by David) about what guidance to >> give about RTCP in draft-ietf-dart-dscp-rtp. We need to close this in order to >> progress the draft--meaning we need to do so ASAP. >> >> Please look at the the following quoted text for background, and offer an >> opinion: >> >> >>> (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. >>> >> _______________________________________________ >> Dart mailing list >> Dart@ietf.org >> https://www.ietf.org/mailman/listinfo/dart > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Mon Aug 25 03:17:49 2014 Return-Path: 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 334A21A8BC1 for ; Mon, 25 Aug 2014 03:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 LupcVJQMzrEe for ; Mon, 25 Aug 2014 03:17:45 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id ABD841A8BBF for ; Mon, 25 Aug 2014 03:17:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 97B207C3F67 for ; Mon, 25 Aug 2014 12:17:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgFFPQmcVc2P for ; Mon, 25 Aug 2014 12:17:41 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:6dc8:104c:7418:7e33] (unknown [IPv6:2001:470:de0a:27:6dc8:104c:7418:7e33]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1025A7C3F65 for ; Mon, 25 Aug 2014 12:17:41 +0200 (CEST) Message-ID: <53FB0D44.9000007@alvestrand.no> Date: Mon, 25 Aug 2014 12:17:40 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: dart@ietf.org References: <62D70F5C-C6CF-48C7-AE9F-55B17172555D@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BB42A9A@MX15A.corp.emc.com> <323887A6-A313-495E-AFFD-B921D3628F72@nostrum.com> In-Reply-To: <323887A6-A313-495E-AFFD-B921D3628F72@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/ZCAgPZ913YY73kHMMXhhVmga3v0 Subject: Re: [Dart] WGLC Comments on draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 10:17:47 -0000 On 08/24/2014 12:50 AM, Ben Campbell wrote: > Hi, comments inline. I deleted sections that do not need to seem further comment (or where the comment would have been "okay"). > > > On Aug 22, 2014, at 7:03 PM, Black, David wrote: > > [...] > >>> -- Abstract (and intro) >>> >>> It's probably worth mentioning that, other than mixing RTP/RTCP, RTP >>> multiplexing is a relatively new thing. It's needed by new work such as WebRTC >>> and clue, and it is enabled by bundle. The point being, this wasn't something >>> we really needed to worry about until now. >> Could you suggest text for the Introduction section, along with any additional references? > Okay, how about something like the following (perhaps inserted after "... including communication based on the Real-time Transport Protocol (RTP)") > > "Historically, distinct RTP streams have been sent over different transport level flows, sometimes multiplexed with RTCP. But recently WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) [RFC4566] bundle negotiation mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] to send multiple streams, potentially needing different QoS treatments, using the same IP 5-tuple." > > [...] >>> -- section 4: >>> >>> It might be nice to have a more WebRTC-ish example. For example an audio >>> stream, video stream, and a data channel carrying something like a shared >>> white board or game. >> Sure, please send text. >> > Okay, how about something like the following, added to the end of section 4: > > "A WebRTC application may carry one or more RTP streams, as discussed above. In addition, it might carry an SCTP data channel. The treatment of the data channel would depend on the nature of the application. For example, messaging applications, shared white board, or guided browsing applications might be best effort, while a latency-sensitive game application might require a higher priority PHB." I would prefer to say "A WebRTC application may use...." - an application is something that lives in a browser at one end of a connection, talking to something at the other end of the connection (might be an instance of the same application, might be something completely different). I would also prefer "might desire" to "might require" - games are unlikely to refuse to operate if they don't get a higher priority PHB, they'll just work with degraded performance. That's nits. > > >>> -- section 6, last bullet: >>> >>> Is there a such thing as "less than best effort traffic" where "best effort" >>> treatments would be unacceptable? >> I can come up with possible examples - background bulk transfer of something >> large that should not interfere with foreground WebRTC data that is being >> carried as best-effort. >>> Actually, it's not clear to me from this paragraph if CS1 is ever appropriate, >>> at least from the application endpoint perspective, as it seem to give >>> completely unpredictable results. >> That was intended - would you like to see stronger language? >> > No, if that is the intent, I am okay with the existing language. > > > [...] > > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Mon Aug 25 04:20:02 2014 Return-Path: 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 672761A9029; Mon, 25 Aug 2014 04:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 E5VlDez2U5YU; Mon, 25 Aug 2014 04:19:54 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164F81A9031; Mon, 25 Aug 2014 04:19:53 -0700 (PDT) Received: from [130.209.247.112] (port=58798 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XLsJR-0002Fo-Nt; Mon, 25 Aug 2014 12:19:51 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BB42A7A@MX15A.corp.emc.com> Date: Mon, 25 Aug 2014 12:19:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <04D677DE-FA18-4917-A973-70D330285197@csperkins.org> References: <8D3D17ACE214DC429325B2B98F3AE712077BB42A7A@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/RXfmYT1WZlw7VgDo91NZhn4BtiM Cc: Ben Campbell , "dart@ietf.org" , "avt@ietf.org WG" , "Paul E. Jones \(paulej@packetizer.com\)" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 11:19:59 -0000 Hi, On 22 Aug 2014, at 21:12, Black, David wrote: > Hi Colin, >=20 > I've picked up your changes (including RTCWEB -> WebRTC globally) > in my working draft, with two exceptions: >=20 > (1) Items 3 and 4 in the list of what can be multiplexed. >=20 > I don't think you suggested any changes to these two items, but > they need significant attention for other reasons: >=20 > - Ben's comment that item 3 ought to focus on the WebRTC data channel > - STUN doesn't encapsulate WebRTC traffic (TURN does). >=20 > 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=92s fine. > (2) PHBs and DSCPs for RTCP. >=20 > 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. =20= >=20 > Colin (from WGLC comments): >=20 >> 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. >=20 > Paul (from shortly after the Toronto meeting: >=20 >> 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. :-) >>=20 >> 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. >>=20 >> 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. >=20 > 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=92m 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=92m not sure that = using a single DSCP for all RTCP packets would achieve that. Colin --=20 Colin Perkins http://csperkins.org/ From nobody Mon Aug 25 11:07:39 2014 Return-Path: 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 DD1FC1A00DC for ; Mon, 25 Aug 2014 11:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 PtPh4vmMPWhR for ; Mon, 25 Aug 2014 11:07:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179ED1A00B5 for ; Mon, 25 Aug 2014 11:07:31 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7PI7AMn051291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2014 13:07:13 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53FB0D44.9000007@alvestrand.no> Date: Mon, 25 Aug 2014 13:07:10 -0500 X-Mao-Original-Outgoing-Id: 430682830.409649-d89c731aa6954172fa0b1bec7175106a Content-Transfer-Encoding: quoted-printable Message-Id: <93495EB5-D93F-436E-BC7A-ED306C23021A@nostrum.com> References: <62D70F5C-C6CF-48C7-AE9F-55B17172555D@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BB42A9A@MX15A.corp.emc.com> <323887A6-A313-495E-AFFD-B921D3628F72@nostrum.com> <53FB0D44.9000007@alvestrand.no> To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/knS9WsImLmE-R5ak3WT-1zMpYx4 Cc: dart@ietf.org Subject: Re: [Dart] WGLC Comments on draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 18:07:36 -0000 On Aug 25, 2014, at 5:17 AM, Harald Alvestrand = wrote: >>>>=20 >>>> It might be nice to have a more WebRTC-ish example. For example an = audio >>>> stream, video stream, and a data channel carrying something like a = shared >>>> white board or game. >>> Sure, please send text. >>>=20 >> Okay, how about something like the following, added to the end of = section 4: >>=20 >> "A WebRTC application may carry one or more RTP streams, as discussed = above. In addition, it might carry an SCTP data channel. The treatment = of the data channel would depend on the nature of the application. For = example, messaging applications, shared white board, or guided browsing = applications might be best effort, while a latency-sensitive game = application might require a higher priority PHB." >=20 > I would prefer to say "A WebRTC application may use...." - an = application is something that lives in a browser at one end of a = connection, talking to something at the other end of the connection = (might be an instance of the same application, might be something = completely different). >=20 > I would also prefer "might desire" to "might require" - games are = unlikely to refuse to operate if they don't get a higher priority PHB, = they'll just work with degraded performance. That's nits. >=20 Harald's suggestions improve the text. I agree with both.= From nobody Mon Aug 25 11:12:17 2014 Return-Path: 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 C5EF51A01EB; Mon, 25 Aug 2014 11:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 EZqA_vo_nmKr; Mon, 25 Aug 2014 11:12:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E2B1A01BA; Mon, 25 Aug 2014 11:12:11 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7PIC16t064980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2014 13:12:02 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <04D677DE-FA18-4917-A973-70D330285197@csperkins.org> Date: Mon, 25 Aug 2014 13:12:01 -0500 X-Mao-Original-Outgoing-Id: 430683121.030512-7861751ea1325f801fdfa23c0d7d403b Content-Transfer-Encoding: quoted-printable Message-Id: <79D2AC8C-4821-4CDA-A39A-7D460DD18A41@nostrum.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BB42A7A@MX15A.corp.emc.com> <04D677DE-FA18-4917-A973-70D330285197@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/zfjhjAJ4eEecyDvI9xL8Dlt0SUI Cc: "Paul E. Jones \(paulej@packetizer.com\)" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 18:12:13 -0000 On Aug 25, 2014, at 6:19 AM, Colin Perkins wrote: >> (2) PHBs and DSCPs for RTCP. >>=20 >> 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. =20= >>=20 >> Colin (from WGLC comments): >>=20 >>> 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. >>=20 >> Paul (from shortly after the Toronto meeting: >>=20 >>> 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. :-) >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >> I'll watch where that discussion goes before proposing text. >=20 > 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. >=20 > Accordingly, I=92m 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=92m 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 nobody Mon Aug 25 12:52:03 2014 Return-Path: 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 7860D1A0308; Mon, 25 Aug 2014 12:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 Uld6W4VHhW24; Mon, 25 Aug 2014 12:51:59 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A941A02F5; Mon, 25 Aug 2014 12:51:59 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s7PJphKT013463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2014 15:51:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1408996306; bh=fBmirMF6f4yVVW3DXovZI5IVY1m6cK4uJ+BvWgokgVI=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=qkmkZ2iTA4dP6+WN7Y1I6fHPPrbAZWOAWHggpkokfftzHbCAsQSHjZg2me0pBW2k0 FcesIaMgZCPkHn5R1BJroAGV+yWnNdfe9bKej/LDQj0sSGnZhYrGbMn5Azj3IOnDW6 hlu2e0kl4rClMbASSbrJ2zbTvfC29jyk+O94Y08g= From: "Paul E. Jones" To: "Ben Campbell" , "Colin Perkins" Date: Mon, 25 Aug 2014 19:52:08 +0000 Message-Id: In-Reply-To: <79D2AC8C-4821-4CDA-A39A-7D460DD18A41@nostrum.com> User-Agent: eM_Client/6.0.20617.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dart/tqvhbeoocUYqss2hfW2AQ0u6xBc Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 19:52:00 -0000 Ben, Colin, On (2) below, it might be a challenge to get agreement quickly, but it=20 might be nice if we could. As this work relates to RMCAT, determining=20 one-way delay or changes thereto will likely prove important. In=20 general, I would expect perceived quality to be important and conveying=20 quality metrics and/or providing feedback to the sender so that=20 perceived quality improves (in whatever form) will be important. I'm=20 suspicious of use of any RTT calculation for any mechanism that might be= =20 used to improve QoE. Getting feedback to the sender is important, though. In an ideal world,= =20 I would argue that RTCP packets should be marked with whatever DSCP=20 value will deliver RTCP packets in the most expedient way. Since we=20 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=20 line (thus, if audio is the first m=3D line in SDP and that flow is=20 active, all RTCP packets will be marked the same as audio) * Specify a value for all RTCP packets irrespective of any value used in= =20 RTP flows I think the right folks on the thread and on the list are present to=20 help make that choice. We just need to decide if that is something we=20 want to specify. Paul ------ Original Message ------ From: "Ben Campbell" To: "Colin Perkins" Cc: "Black, David" ; "dart@ietf.org"=20 ; "avt@ietf.org WG" ; "Paul E. Jones=20 (paulej@packetizer.com)" ;=20 "draft-ietf-dart-dscp-rtp.all@tools.ietf.org"=20 Sent: 8/25/2014 2:12:01 PM Subject: Re: [Dart] Colin Perkins comments - WGLC:=20 draft-ietf-dart-dscp-rtp-02 > >On Aug 25, 2014, at 6:19 AM, Colin Perkins wrote: > >>> (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,=20 >>>>and that >>>> report on the reception quality of RTP streams being received.=20 >>>>Using a single >>>> PHB and DSCP for all RTCP packets within an RTP session might make= =20 >>>>sense, but >>>> it's important to note that one role of RTCP is to provide an=20 >>>>estimate of the >>>> round-trip time seen by the media, so the PHB/DSCP will have to be= =20 >>>>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.=20 >>>>Some >>>> notes I received on this topic suggested that it was proposed that= =20 >>>>RTCP >>>> should be marked the same as for RTP. The argument was that this is= =20 >>>>used >>>> for RTT calculations. If that is what was said, I'd like to state=20 >>>>my >>>> disagreement. :-) >>>> >>>> The forward and reverse paths are not necessarily the same and=20 >>>>there is >>>> nothing one should assume about the reverse path to provide=20 >>>>guidance about >>>> the forward path (or vice versa). As perhaps a gross example, I=20 >>>>have the >>>> ability to download far faster on my home Internet connection than= =20 >>>>I can >>>> upload. Other important traffic characteristics differ in each=20 >>>>direction. >>>> >>>> Further, an RTCP packet might provide information related to=20 >>>>several different >>>> RTP packets. I certainly would not want to see one RTCP packet per= =20 >>>>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,= =20 >>as described in Section 6.4.1 (page 41) of RFC 3550. The DSCP marking=20 >>used for RTCP does need to take this use into account. Ideally, this=20 >>would mean RTCP packets were marked the same as the corresponding RTP=20 >>packets, as I suggested in the meeting. However, Paul is correct that=20 >>this only works when all RTP packets have the same marking. >> >> Accordingly, I=E2=80=99m not sure what the right marking is for RTCP.= One=20 >>approach might be to say that an SSRC that sends RTP packets with=20 >>different marking should use marking with the highest(lowest?)=20 >>precedence of those is uses for RTCP, so the RTT estimate calculated=20 >>from RTCP is representative of some RTP packets. I=E2=80=99m not sure = that=20 >>using a single DSCP for all RTCP packets would achieve that. > >Can this working group reasonably answer this question? If not, we=20 >could list it as something implementors need to think about, and note=20 >that we do not have generic guidance. > From nobody Mon Aug 25 13:12:21 2014 Return-Path: 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 2984C1A0322; Mon, 25 Aug 2014 13:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 AX0-AwbUgkB6; Mon, 25 Aug 2014 13:12:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2BCE1A02F3; Mon, 25 Aug 2014 13:12:16 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7PKC4HL089653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2014 15:12:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Mon, 25 Aug 2014 15:12:04 -0500 X-Mao-Original-Outgoing-Id: 430690323.979285-1205ab60f603b33e7c926ff420472499 Content-Transfer-Encoding: quoted-printable Message-Id: <1ACE6E53-8B4D-4DB8-9269-DF518289DBEC@nostrum.com> References: To: "Paul E. Jones" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/kwT5DG03b2iwLU7HC_kDB3od3k4 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , Colin Perkins , "avt@ietf.org WG" Subject: Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 20:12:19 -0000 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 = wrote: > Ben, Colin, >=20 > 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. >=20 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. >=20 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. > 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=3D 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 >=20 > 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. >=20 > Paul >=20 > ------ Original Message ------ > From: "Ben Campbell" > To: "Colin Perkins" > Cc: "Black, David" ; "dart@ietf.org" = ; "avt@ietf.org WG" ; "Paul E. Jones = (paulej@packetizer.com)" ; = "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" = > Sent: 8/25/2014 2:12:01 PM > Subject: Re: [Dart] Colin Perkins comments - WGLC: = draft-ietf-dart-dscp-rtp-02 >=20 >>=20 >> On Aug 25, 2014, at 6:19 AM, Colin Perkins wrote: >>=20 >>>> (2) PHBs and DSCPs for RTCP. >>>>=20 >>>> 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. >>>>=20 >>>> Colin (from WGLC comments): >>>>=20 >>>>> 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. >>>>=20 >>>> Paul (from shortly after the Toronto meeting: >>>>=20 >>>>> 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. :-) >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>=20 >>>> I'll watch where that discussion goes before proposing text. >>>=20 >>> 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. >>>=20 >>> Accordingly, I=92m 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=92m not sure that = using a single DSCP for all RTCP packets would achieve that. >>=20 >> 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. >>=20 >=20 From nobody Mon Aug 25 14:59:19 2014 Return-Path: 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 5FF8B1A03C0; Mon, 25 Aug 2014 14:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.26 X-Spam-Level: X-Spam-Status: No, score=-0.26 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 0hqoTa5zlb8d; Mon, 25 Aug 2014 14:59:10 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36EB71A03BD; Mon, 25 Aug 2014 14:59:10 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s7PLwvZI022051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2014 17:58:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1409003938; bh=c8TQR4nWIS5LOs0EvnO1BzAkEoKoDwQw3B3ppwnIecg=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=BB6q3QrRqIgdI96wJaGXnFPjn4Ak5Y/6p1eAVse/Baxx8/1g8e3CPkAwmxTw+g4MI UNyD2TsYsoL9lX0MuRstk/NnkoGBoRbGtZYPhMHv6yyv3q7rdI49DE3HMqgBUiA7/+ gN1vprUXce/uAC27tOgCZjP+Vvuo8U7fvypeOQT8= From: "Paul E. Jones" To: "Ben Campbell" Date: Mon, 25 Aug 2014 21:59:22 +0000 Message-Id: In-Reply-To: <1ACE6E53-8B4D-4DB8-9269-DF518289DBEC@nostrum.com> User-Agent: eM_Client/6.0.20617.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dart/tnT2ZLnPqVORVNGI-6FwyfxAih8 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , Colin Perkins , "avt@ietf.org WG" Subject: Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 21:59:13 -0000 Ben, >Our charter is not to improve QoS or solve congestion issues. It's just= =20 >to give guidance on DSCP choices for multiplexed media. So I think the=20 >question becomes, has RMCAT made decisions (or looks very likely to=20 >make decisions) to use RTCP in a way that would be impacted by our DSCP= =20 >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=20 >>it might be nice if we could. As this work relates to RMCAT,=20 >>determining one-way delay or changes thereto will likely prove=20 >>important. In general, I would expect perceived quality to be=20 >>important and conveying quality metrics and/or providing feedback to=20 >>the sender so that perceived quality improves (in whatever form) will=20 >>be important. I'm suspicious of use of any RTT calculation for any=20 >>mechanism that might be used to improve QoE. >> > >If so, then we should document the potential impact. If _not_, then it=20 >seems to me the best we could do is mention that RTCP treatments may or= =20 >may not have an impact on RTT estimates, and that the implementer=20 >should think about it. If accurate RTT measurements could be made, they could be useful. The=20 problem is that in some environments, we know that RTTs will not be=20 accurate. Sometimes they are, of course. We could have some text as you suggest, but I would personally prefer we= =20 not encourage use of RTT values for any particular purpose. :-) >> Getting feedback to the sender is important, though. In an ideal=20 >>world, I would argue that RTCP packets should be marked with whatever=20 >>DSCP value will deliver RTCP packets in the most expedient way. Since=20 >>we don't have an ideal world, I don't know which DSCP value that would= =20 >>be. >> > >Would the starting positions of "getting feedback is important, even of= =20 >not for RTT estimates" and "we need RTCP for RTT estimates" likely land= =20 >on the same guidance for DSCP values? > >The argument to send RTCP packets in the most expedient way sounds=20 >reasonable. I don't know if we need to recommend a particular DSCP,=20 >since we already have quite a bit of text on how DSCPs might (or might=20 >not) map into some predictable PHB treatment. Good question and valid point. Nowhere in the document do we recommend=20 the use of a particular DSCP value for any particular thing, and we=20 should not recommend a particular value for RTCP in this document. I'm=20 just not sure what statements should be made. I suspect we can all agree that RTCP information is important. It's=20 just the DSCP-related guidance that goes with that that is challenging. David? :-) Paul From nobody Mon Aug 25 23:07:31 2014 Return-Path: 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 124841A067D for ; Mon, 25 Aug 2014 23:07:29 -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 LNPPQgUbqMg2 for ; Mon, 25 Aug 2014 23:07:26 -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 42D201A0653 for ; Mon, 25 Aug 2014 23:07:26 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7Q67MXt002153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2014 02:07:22 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s7Q67MXt002153 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409033243; bh=CM9MNb2WjzwAI2+HQADkF77FsvU=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=HzownwYEYCJKI2BV7+QfUtIpULhPp5McmlBWSoyZYjTWzIf39QGQ3q5eS2AO4GYfw gd/PfgYnP8bVHpakVPwfMXGpaSiHjKtB1lRowSoZFl7WveQZnqKfHXVbAVm88o+oaf anNVTo/dWDuFwhE6VbwjyEVZeyq8MX03NCWW4MMw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s7Q67MXt002153 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd05.lss.emc.com (RSA Interceptor); Tue, 26 Aug 2014 02:07:06 -0400 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7Q674W3021192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 02:07:06 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Tue, 26 Aug 2014 02:07:04 -0400 From: "Black, David" To: Harald Alvestrand , "dart@ietf.org" Date: Tue, 26 Aug 2014 02:07:02 -0400 Thread-Topic: draft-ietf-dart-dscp-rtp-02 - Section 4 data channel text Thread-Index: Ac/A8/JUTzsBwNj8RPOI+dzvT/1H7Q== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42CEA@MX15A.corp.emc.com> 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: mailusrhubprd03.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/sD9q9ghV4qPxg3VRRXJ1Ce9I8Kw Subject: [Dart] draft-ietf-dart-dscp-rtp-02 - Section 4 data channel text X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 06:07:29 -0000 > >>> -- section 4: > >>> > >>> It might be nice to have a more WebRTC-ish example. For example an au= dio > >>> stream, video stream, and a data channel carrying something like a sh= ared > >>> white board or game. > >> Sure, please send text. > >> > > Okay, how about something like the following, added to the end of secti= on 4: > > > > "A WebRTC application may carry one or more RTP streams, as discussed a= bove. > In addition, it might carry an SCTP data channel. The treatment of the da= ta > channel would depend on the nature of the application. For example, messa= ging > applications, shared white board, or guided browsing applications might b= e > best effort, while a latency-sensitive game application might require a h= igher > priority PHB." >=20 > I would prefer to say "A WebRTC application may use...." - an > application is something that lives in a browser at one end of a > connection, talking to something at the other end of the connection > (might be an instance of the same application, might be something > completely different). >=20 > I would also prefer "might desire" to "might require" - games are > unlikely to refuse to operate if they don't get a higher priority PHB, > they'll just work with degraded performance. That's nits. Done, plus some more editing, here's the result in my working draft: A WebRTC application may use one or more RTP streams, as discussed above. In addition, it may include an SCTP-based data channel [I-D.ietf-rtcweb-data-channel] whose QoS treatment depends on the nature of the application. For example, best effort treatment of data channels is likely to suffice for messaging, shared white board, and guided browsing applications, whereas latency-sensitive games might desire better QoS for their data channels. From nobody Tue Aug 26 03:17:38 2014 Return-Path: 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 588561A6F20; Tue, 26 Aug 2014 03:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 JxBSw7FAxqDv; Tue, 26 Aug 2014 03:17:19 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367DF1A6F2A; Tue, 26 Aug 2014 03:17:11 -0700 (PDT) Received: from [130.209.247.112] (port=55276 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XMDoI-0004l0-JB; Tue, 26 Aug 2014 11:17:07 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Tue, 26 Aug 2014 11:17:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5B9EC18C-A2E6-4A62-AF5F-C24A09AEC7F0@csperkins.org> References: To: "Paul E. Jones" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/0czSbM2k95gK6HQXpQ-xWPe7Tmk Cc: Ben Campbell , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:17:21 -0000 On 25 Aug 2014, at 22:59, Paul E. Jones wrote: > Ben, >=20 >> 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? >=20 > I=92m not aware of whether such a decision has been made. I don=92t believe RMCAT has considered this issue. >>> Ben, Colin, >>>=20 >>> 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. >>>=20 >>=20 >> 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. >=20 > 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. >=20 > We could have some text as you suggest, but I would personally prefer = we not encourage use of RTT values for any particular purpose. :-) >=20 >=20 >>> 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. >>=20 >> 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? >>=20 >> 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. >=20 > 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. >=20 > 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=92t 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=92s in base RTP specification, and so is = something we need to support to the extent possible.=20 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. --=20 Colin Perkins http://csperkins.org/ From nobody Tue Aug 26 03:22:02 2014 Return-Path: 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 C2C791A6F32; Tue, 26 Aug 2014 03:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 uN9JPSYjWGsW; Tue, 26 Aug 2014 03:21:46 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576451A6F27; Tue, 26 Aug 2014 03:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=832; q=dns/txt; s=iport; t=1409048506; x=1410258106; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/iGBihFt8i7AJr8IR9DPPFa1l4M0jKDXA+sOPCDJpfU=; b=l5lpuvWnrLPR4q0zZhuGrmkdMempXk0YTg5In0tIKtdnHkffTnBvY5+2 URZ+kfsFvd4ZvXwpIEgjuXyPZSM++Vc/mkQx2Gfpx0OvQGwKgCS3TIgP+ vbBKU5jwbSlXobo3m7NG7n5C84Hydv5S2yiZSsNin5xr4FtrvC7zETwKm o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAJZf/FOtJV2Q/2dsb2JhbABagmojgSoE1B0BgRYWd4QEAQEDAXkQAgEIDjgyJQIEDgWIOggBvlkXjxkzB4MvgR0BBJEmiyOVDINebIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,403,1406592000"; d="scan'208";a="350309530" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP; 26 Aug 2014 10:21:38 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7QALcl9007391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 10:21:38 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 05:21:38 -0500 From: "Ali C. Begen (abegen)" To: Colin Perkins Thread-Topic: [AVTCORE] [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 Thread-Index: AQHPwJ4NU171D3mkRUC1qllSsf8d+JviFEIAgAAd+gCAAM4ZgIAAAUmA Date: Tue, 26 Aug 2014 10:21:37 +0000 Message-ID: <6F3FF603-E7D8-4EAB-86D5-F5FFC851BF3C@cisco.com> References: <5B9EC18C-A2E6-4A62-AF5F-C24A09AEC7F0@csperkins.org> In-Reply-To: <5B9EC18C-A2E6-4A62-AF5F-C24A09AEC7F0@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.238] Content-Type: text/plain; charset="Windows-1252" Content-ID: <66A268BE4BBF7A4CA56425969EF12A65@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/vQcX8EAWtfM4FEpUaoSSATtlNz4 Cc: "Paul E. Jones" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [Dart] [AVTCORE] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:21:54 -0000 On Aug 26, 2014, at 1:17 PM, Colin Perkins wrote: >> I suspect we can all agree that RTCP information is important. It's jus= t the DSCP-related guidance that goes with that that is challenging. >=20 > I don=92t agree that RTCP information should be sent as higher priority t= han the media. Ideally, it should be sent with the same priority as the med= ia, so it can be used to sample the RTT. This RTT sample is independent of = RMCAT.=20 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 traf= fic. If you want protection for RTCP packets, use redundancy or other techn= iques within the bounds allowed by 3550. = From nobody Tue Aug 26 07:16:32 2014 Return-Path: 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 EB8391A702E; Tue, 26 Aug 2014 07:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 9T2lgqDlMyMi; Tue, 26 Aug 2014 07:16:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9AA11A7023; Tue, 26 Aug 2014 07:16:24 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7QEGC2E085675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2014 09:16:13 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <5B9EC18C-A2E6-4A62-AF5F-C24A09AEC7F0@csperkins.org> Date: Tue, 26 Aug 2014 09:16:11 -0500 X-Mao-Original-Outgoing-Id: 430755371.548291-a6cbdebbc0c56f496d11c0ab61f26568 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B9EC18C-A2E6-4A62-AF5F-C24A09AEC7F0@csperkins.org> To: Colin Perkins , "Paul E. Jones" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Y63PYWIpkoIqw2RN3UmOIczoNZk Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 14:16:29 -0000 On Aug 26, 2014, at 5:17 AM, Colin Perkins wrote: >>>>=20 >>>> 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. >>>=20 >>> 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? >>>=20 >>> 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. >>=20 >> 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. >>=20 >> 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. >=20 > I don=92t 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=92s in base RTP specification, and so = is something we need to support to the extent possible.=20 >=20 > 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. That makes sense to me. Paul, and others, do you agree with that last = paragraph? /Ben From nobody Tue Aug 26 07:38:46 2014 Return-Path: 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 043911A86EF for ; Tue, 26 Aug 2014 07:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 S_xjcCKGQUPP for ; Tue, 26 Aug 2014 07:38:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685AF1A86F2 for ; Tue, 26 Aug 2014 07:38:43 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7QEcKZQ087667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2014 09:38:21 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BB42CEA@MX15A.corp.emc.com> Date: Tue, 26 Aug 2014 09:38:19 -0500 X-Mao-Original-Outgoing-Id: 430756699.809075-fdac62a0b9e17126b4d199066d878588 Content-Transfer-Encoding: quoted-printable Message-Id: <289B2FA8-457F-4CF2-BA72-CF0DA947CE11@nostrum.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BB42CEA@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/mvvpZwMo5GrRunftILt5tSRcZw4 Cc: Harald Tveit Alvestrand , "dart@ietf.org" Subject: Re: [Dart] draft-ietf-dart-dscp-rtp-02 - Section 4 data channel text X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 14:38:45 -0000 On Aug 26, 2014, at 1:07 AM, Black, David wrote: >>>>> -- section 4: >>>>>=20 >>>>> It might be nice to have a more WebRTC-ish example. For example an = audio >>>>> stream, video stream, and a data channel carrying something like a = shared >>>>> white board or game. >>>> Sure, please send text. >>>>=20 >>> Okay, how about something like the following, added to the end of = section 4: >>>=20 >>> "A WebRTC application may carry one or more RTP streams, as = discussed above. >> In addition, it might carry an SCTP data channel. The treatment of = the data >> channel would depend on the nature of the application. For example, = messaging >> applications, shared white board, or guided browsing applications = might be >> best effort, while a latency-sensitive game application might require = a higher >> priority PHB." >>=20 >> I would prefer to say "A WebRTC application may use...." - an >> application is something that lives in a browser at one end of a >> connection, talking to something at the other end of the connection >> (might be an instance of the same application, might be something >> completely different). >>=20 >> I would also prefer "might desire" to "might require" - games are >> unlikely to refuse to operate if they don't get a higher priority = PHB, >> they'll just work with degraded performance. That's nits. >=20 > Done, plus some more editing, here's the result in my working draft: >=20 > A WebRTC application may use one or more RTP streams, as discussed > above. In addition, it may include an SCTP-based data channel > [I-D.ietf-rtcweb-data-channel] whose QoS treatment depends on the > nature of the application. For example, best effort treatment of > data channels is likely to suffice for messaging, shared white = board, > and guided browsing applications, whereas latency-sensitive games > might desire better QoS for their data channels. >=20 WFM. From nobody Tue Aug 26 08:40:09 2014 Return-Path: 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 E357D1A875A for ; Tue, 26 Aug 2014 08:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 rRvggymW9S7P for ; Tue, 26 Aug 2014 08:40:01 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id BCB331A8753 for ; Tue, 26 Aug 2014 08:40:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A11F87C3FB9; Tue, 26 Aug 2014 17:39:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NOZETApN568; Tue, 26 Aug 2014 17:39:57 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:58e1:effa:69ad:eb6f] (unknown [IPv6:2001:470:de0a:27:58e1:effa:69ad:eb6f]) by mork.alvestrand.no (Postfix) with ESMTPSA id 78E507C3FB8; Tue, 26 Aug 2014 17:39:57 +0200 (CEST) Message-ID: <53FCAA4A.8040908@alvestrand.no> Date: Tue, 26 Aug 2014 17:39:54 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ben Campbell , "Black, David" References: <8D3D17ACE214DC429325B2B98F3AE712077BB42CEA@MX15A.corp.emc.com> <289B2FA8-457F-4CF2-BA72-CF0DA947CE11@nostrum.com> In-Reply-To: <289B2FA8-457F-4CF2-BA72-CF0DA947CE11@nostrum.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/k-U0oVQ3kc9Vi_soaucKZhhfGqM Cc: "dart@ietf.org" Subject: Re: [Dart] draft-ietf-dart-dscp-rtp-02 - Section 4 data channel text X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 15:40:06 -0000 On 08/26/2014 04:38 PM, Ben Campbell wrote: > On Aug 26, 2014, at 1:07 AM, Black, David wrote: > >>>>>> -- section 4: >>>>>> >>>>>> It might be nice to have a more WebRTC-ish example. For example an audio >>>>>> stream, video stream, and a data channel carrying something like a shared >>>>>> white board or game. >>>>> Sure, please send text. >>>>> >>>> Okay, how about something like the following, added to the end of section 4: >>>> >>>> "A WebRTC application may carry one or more RTP streams, as discussed above. >>> In addition, it might carry an SCTP data channel. The treatment of the data >>> channel would depend on the nature of the application. For example, messaging >>> applications, shared white board, or guided browsing applications might be >>> best effort, while a latency-sensitive game application might require a higher >>> priority PHB." >>> >>> I would prefer to say "A WebRTC application may use...." - an >>> application is something that lives in a browser at one end of a >>> connection, talking to something at the other end of the connection >>> (might be an instance of the same application, might be something >>> completely different). >>> >>> I would also prefer "might desire" to "might require" - games are >>> unlikely to refuse to operate if they don't get a higher priority PHB, >>> they'll just work with degraded performance. That's nits. >> Done, plus some more editing, here's the result in my working draft: >> >> A WebRTC application may use one or more RTP streams, as discussed >> above. In addition, it may include an SCTP-based data channel >> [I-D.ietf-rtcweb-data-channel] whose QoS treatment depends on the >> nature of the application. For example, best effort treatment of >> data channels is likely to suffice for messaging, shared white board, >> and guided browsing applications, whereas latency-sensitive games >> might desire better QoS for their data channels. >> > WFM. Works for me too. If I was nitpicking, I would change "it may include" to "it may use" in sentence 2 too, but I can live with this just fine. > -- Surveillance is pervasive. Go Dark. From nobody Tue Aug 26 08:40:17 2014 Return-Path: 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 68FB81A8753; Tue, 26 Aug 2014 08:40:07 -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 j3x47P62Jdct; Tue, 26 Aug 2014 08:40:05 -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 295241A8758; Tue, 26 Aug 2014 08:40:00 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7QFdtKV026108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2014 11:39:56 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7QFdtKV026108 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409067597; bh=qbgpZId3smQGl8aMlKWBtmJ7fdg=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=dou2JrX0/k/hb0we0AKlcaI5vfcYhqzX8JbCxoihNJtQfEVDDOnJOalVwGMtXKnBN MFN/BjUK1XxBh8MsUQkIHMYzaCqOnKag62eBvN/TW7euhqK0vfImQKg1gErQFpg1u1 wf0J6qpPyh8+Ck0kW4JaTp7jv/4O3nA/7gbsnwHQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7QFdtKV026108 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd06.lss.emc.com (RSA Interceptor); Tue, 26 Aug 2014 11:39:35 -0400 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7QFdixV032109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 11:39:45 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Tue, 26 Aug 2014 11:39:44 -0400 From: "Black, David" To: Ben Campbell , Colin Perkins , "Paul E. Jones" Date: Tue, 26 Aug 2014 11:39:43 -0400 Thread-Topic: Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) Thread-Index: Ac/BOFPJlhOxAYxzTYOsMDJmQY77lAACangA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42DF4@MX15A.corp.emc.com> References: <5B9EC18C-A2E6-4A62-AF5F-C24A09AEC7F0@csperkins.org> In-Reply-To: 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: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/b1oazwmr2a8B972C5XitU38FoQg Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 15:40:07 -0000 > > 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 on= e 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 packe= ts it > sends. >=20 > That makes sense to me. Paul, and others, do you agree with that last > paragraph? 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. 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!).=20 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 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, August 26, 2014 10:16 AM > To: Colin Perkins; Paul E. Jones > Cc: Black, David; dart@ietf.org; avt@ietf.org WG; draft-ietf-dart-dscp- > rtp.all@tools.ietf.org > Subject: Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC: > draft-ietf-dart-dscp-rtp-02) >=20 >=20 > On Aug 26, 2014, at 5:17 AM, Colin Perkins wrote: >=20 > >>>> > >>>> Getting feedback to the sender is important, though. In an ideal wor= ld, I > would argue that RTCP packets should be marked with whatever DSCP value w= ill > deliver RTCP packets in the most expedient way. Since we don't have an id= eal > 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 o= n 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 in= to > some predictable PHB treatment. > >> > >> Good question and valid point. Nowhere in the document do we recommen= d the > use of a particular DSCP value for any particular thing, and we should no= t > recommend a particular value for RTCP in this document. I'm just not sur= e > what statements should be made. > >> > >> I suspect we can all agree that RTCP information is important. It's j= ust > the DSCP-related guidance that goes with that that is challenging. > > > > I don't agree that RTCP information should be sent as higher priority t= han > 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 on= e 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 packe= ts it > sends. >=20 > That makes sense to me. Paul, and others, do you agree with that last > paragraph? >=20 > /Ben >=20 From nobody Tue Aug 26 08:52:42 2014 Return-Path: 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 DA2E31A8716; Tue, 26 Aug 2014 08:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 4u0nJwFyaKLs; Tue, 26 Aug 2014 08:52:37 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54BD1A870A; Tue, 26 Aug 2014 08:52:37 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s7QFqVYj027374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2014 11:52:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1409068351; bh=y97VtMDdq65PpFzPv+9GBxG2BQp9KptsVXLi5erMno4=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=NPDwZ45mbJTMui7O5mbr35a/fjvGjfSeJitdSxim8ok24SgN8vPuAzgudoCtnDEFI FI5fShbozM5Alq0d14G+MWvb5KdfYKb+VE0XuqzA+XXhqGyZ++tBEtn+pT/ICyQBR6 4hnCJzpZCyoHcjUiYqS1p0DcbE2B8lrtPqN9jYBY= From: "Paul E. Jones" To: "Ben Campbell" , "Colin Perkins" Date: Tue, 26 Aug 2014 15:52:57 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.20617.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dart/3cf5hSxC5F9orn49y9YY54sosLI Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 15:52:40 -0000 Ben, >>>>> Getting feedback to the sender is important, though. In an ideal=20 >>>>>world, I would argue that RTCP packets should be marked with=20 >>>>>whatever DSCP value will deliver RTCP packets in the most expedient= =20 >>>>>way. Since we don't have an ideal world, I don't know which DSCP=20 >>>>>value that would be. >>>> >>>> Would the starting positions of "getting feedback is important,=20 >>>>even of not for RTT estimates" and "we need RTCP for RTT estimates"=20 >>>>likely land on the same guidance for DSCP values? >>>> >>>> The argument to send RTCP packets in the most expedient way sounds= =20 >>>>reasonable. I don't know if we need to recommend a particular DSCP,=20 >>>>since we already have quite a bit of text on how DSCPs might (or=20 >>>>might not) map into some predictable PHB treatment. >>> >>> Good question and valid point. Nowhere in the document do we=20 >>>recommend the use of a particular DSCP value for any particular=20 >>>thing, and we should not recommend a particular value for RTCP in=20 >>>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= =20 >>>just the DSCP-related guidance that goes with that that is=20 >>>challenging. >> >> I don=E2=80=99t agree that RTCP information should be sent as higher= priority=20 >>than the media. Ideally, it should be sent with the same priority as=20 >>the media, so it can be used to sample the RTT. This RTT sample is=20 >>independent of RMCAT. It=E2=80=99s in base RTP specification, and so is= =20 >>something we need to support to the extent possible. >> >> Since not all the media sent by a single SSRC has the same marking,=20 >>my suggestion would be that each SSRC mark the RTCP packets it sends=20 >>with one of the same code points as it uses to mark the media. Since=20 >>RTCP is somewhat important, it would make sense for each SSRC to mark=20 >>the RTCP packets it sends using the highest priority code point it=20 >>uses to mark the RTP media packets it sends. > >That makes sense to me. Paul, and others, do you agree with that last=20 >paragraph? I agree that the value should be one of the values used for media, but=20 the challenge is specifying which DSCP value to use. If audio is sent=20 using EF, video as AF41, app sharing video as AF31, etc., which of these= =20 does the endpoint choose to use for RTCP? Since DSCP values cannot be assumed to any particular PHB behavior in=20 the network, that makes answering that question challenging. My personal preference in a voice/video conference would be to use the=20 same marking as is used for those flows -- and I would use the same=20 value for both voice and video. However, if the app sharing video is=20 considered more important by some applications, perhaps that's the value= =20 that should be used in those applications. I can accept the suggestion, leaving the specific selection as an=20 implementation matter. I do wish there was something more concrete so=20 that two devices would always follow the same approach to selecting a=20 value, but I doubt we can get agreement very quickly. Paul From nobody Tue Aug 26 08:53:58 2014 Return-Path: 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 A8ACA1A875A; Tue, 26 Aug 2014 08:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9XCUdtDaPUUM; Tue, 26 Aug 2014 08:53:54 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71DC1A873A; Tue, 26 Aug 2014 08:53:53 -0700 (PDT) Received: from [130.209.247.112] (port=57972 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XMJ4A-0003Ov-HU; Tue, 26 Aug 2014 16:53:50 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BB42DF4@MX15A.corp.emc.com> Date: Tue, 26 Aug 2014 16:53:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <641FDB1F-F602-4F91-9012-514F84C90462@csperkins.org> References: <5B9EC18C-A2E6-4A62-AF5F-C24A09AEC7F0@csperkins.org> <8D3D17ACE214DC429325B2B98F3AE712077BB42DF4@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/snptCGr21FW9mNNxspXgpWXYq9Q Cc: Ben Campbell , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , "avt@ietf.org WG" , "Paul E. Jones" Subject: Re: [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 15:53:55 -0000 On 26 Aug 2014, at 16:39, Black, David wrote: >>> 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. >>=20 >> That makes sense to me. Paul, and others, do you agree with that last >> paragraph? >=20 > >=20 > 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. >=20 > >=20 > 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!).=20 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.=20 > That statement seems valuable to make and can be made with a citation = of > RFC 3530, as opposed to the multi-stream optimization draft. >=20 > 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. --=20 Colin Perkins http://csperkins.org/ From nobody Tue Aug 26 09:19:18 2014 Return-Path: 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 7EB081A003A; Tue, 26 Aug 2014 09:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qCd8S_fr7Vzs; Tue, 26 Aug 2014 09:19:13 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03BD21A0019; Tue, 26 Aug 2014 09:19:13 -0700 (PDT) Received: from [130.209.247.112] (port=58039 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XMJSd-0005xS-KR; Tue, 26 Aug 2014 17:19:09 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Tue, 26 Aug 2014 17:19:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> References: To: "Paul E. Jones" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/G098GmycIPnDbmUa2noa_GPwa0g Cc: Ben Campbell , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 16:19:15 -0000 On 26 Aug 2014, at 16:52, Paul E. Jones wrote: > Ben, >>>>>> 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. >>>>>=20 >>>>> 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? >>>>>=20 >>>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>=20 >>> I don=92t 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=92s in base RTP specification, and so = is something we need to support to the extent possible. >>>=20 >>> 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. >>=20 >> That makes sense to me. Paul, and others, do you agree with that last = paragraph? >=20 > 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 =20 > Since DSCP values cannot be assumed to any particular PHB behavior in = the network, that makes answering that question challenging. >=20 > 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. >=20 > 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. >=20 > Paul >=20 --=20 Colin Perkins http://csperkins.org/ From nobody Tue Aug 26 09:27:34 2014 Return-Path: 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 6EF821A0032; Tue, 26 Aug 2014 09:27:29 -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 vPBTQgYBG5vU; Tue, 26 Aug 2014 09:27:27 -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 240C31A005B; Tue, 26 Aug 2014 09:27:26 -0700 (PDT) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7QGRKnh005128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2014 12:27:20 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7QGRKnh005128 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409070441; bh=WTSqXLhpK1P2pcTiRbuW3LFpoOw=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=vVgd1ZpKCsMUxQHUxLI9SIE99JVfKFo+eZCpzpGuXF3tXA9qfbxCf56L4Mm3P8DlF FGCulqFcp8RdFzcshRVhgn+gXNAVsdZwZsJ1v/oiSiB+UY/FtccBc+NcHW9QI8x24U oXOdUSaSbb4sI34xq+IrpwjQ09kEr8IePCIrRXlQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7QGRKnh005128 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd54.lss.emc.com (RSA Interceptor); Tue, 26 Aug 2014 12:27:17 -0400 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7QGRGYK008379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 12:27:17 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Tue, 26 Aug 2014 12:27:16 -0400 From: "Black, David" To: Colin Perkins Date: Tue, 26 Aug 2014 12:27:14 -0400 Thread-Topic: [Dart] draft-ietf-dart-dscp-rtp-02 - Section 5.3 RTCP multi-stream optimization text Thread-Index: Ac/BSor8zTj9EwrRQYyUA45HfPyQGw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42E15@MX15A.corp.emc.com> 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/Joido0OU3XSB-Z2O1p6m5ZLissA Cc: Ben Campbell , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , "avt@ietf.org WG" , "Paul E. Jones" Subject: Re: [Dart] draft-ietf-dart-dscp-rtp-02 - Section 5.3 RTCP multi-stream optimization text X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 16:27:29 -0000 Colin writes: The discussion of the multi-stream-optimisation draft is a separate issue, and is correct as it is. Looking closer, that discussion in the current DART draft currently says: 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. That's based on this text from the last paragraph of Section 1 (Introduction) of the multi-stream optimization draft: This memo defines such an RTCP extension, RTCP Reporting Groups. This extension is used to indicate the SSRCs that originate from the same endpoint, and therefore have identical reception quality, hence allowing the endpoints to suppress unnecessary RTCP reception quality reports. When different DSCPs are used for SSRCs (RTP streams) that originate from the same source, the statement that they "therefore have identical reception quality" is clearly incorrect, so it looks like the current DART draft text is correct, IMHO. Harald? Thanks, --David > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Tuesday, August 26, 2014 11:54 AM > To: Black, David > Cc: Ben Campbell; Paul E. Jones; dart@ietf.org; avt@ietf.org WG; draft-ie= tf- > dart-dscp-rtp.all@tools.ietf.org > Subject: Re: Treatment of RTCP (was Re: [Dart] Colin Perkins comments - W= GLC: > draft-ietf-dart-dscp-rtp-02) >=20 >=20 > On 26 Aug 2014, at 16:39, Black, David wrote: >=20 > >>> Since not all the media sent by a single SSRC has the same marking, m= y > >> 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 somew= hat > >> 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 pa= ckets > it > >> sends. > >> > >> That makes sense to me. Paul, and others, do you agree with that last > >> paragraph? > > > > > > > > Sure, when there's a notion of priority or importance. There won't alw= ays > > be one (e.g., is CS2 higher priority than AF2x? That depends ...). OT= OH, > > we don't need to say much here, e.g., the class selector codepoints (CS= x) > > are ordered, and adding a pointer to draft-ietf-tsvwg-rtcweb-qos will b= e > > helpful. > > > > > > > > Turning to the other RTCP issue, [F] on multi-stream optimization, I wo= nder > > whether we inadvertently framed that issue backwards. Given the above,= a > > single RTCP report on multiple RTP streams that use rather different DS= CPs > > may not result in representative RTT values for all of the streams, bec= ause > > the report has to be sent with one DSCP. If that outcome is a problem, > > one should send separate RTCP reports (duh!). >=20 > 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 marki= ngs > for the RTP media packets it sends. >=20 > > That statement seems valuable to make and can be made with a citation o= f > > RFC 3530, as opposed to the multi-stream optimization draft. > > > > Harald and Colin - what do you think? >=20 > The discussion of the multi-stream-optimisation draft is a separate issue= , and > is correct as it is. >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 From nobody Tue Aug 26 09:38:58 2014 Return-Path: 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 019FA1A0066; Tue, 26 Aug 2014 09:38:57 -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 d-MSaVrJG-_5; Tue, 26 Aug 2014 09:38:55 -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 166761A00BF; Tue, 26 Aug 2014 09:38:49 -0700 (PDT) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7QGcga1026065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2014 12:38:44 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s7QGcga1026065 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409071124; bh=/QvO29v7o00UbyFi6Dyv6jRDj8U=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=pV6XnTDtqmZUuW13SBrUSMvUKh8kNeNy7Bs6uA/wt0OvNizBnJR2kU73bm6/8H6Aa oQcwQz3MoHcaMw88kpdgPPBAi2jhVrmlWY9ZKtNb3uG6IcQTM3h1PdlEU9mdnHIxnV he5xiH6Vb6ADR01D4RYoN3I2OFaAxUOl6uEEBlzc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s7QGcga1026065 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd04.lss.emc.com (RSA Interceptor); Tue, 26 Aug 2014 12:38:21 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7QGcRxc005147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 12:38:27 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Tue, 26 Aug 2014 12:38:27 -0400 From: "Black, David" To: Colin Perkins , "Paul E. Jones" Date: Tue, 26 Aug 2014 12:38:22 -0400 Thread-Topic: Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) Thread-Index: Ac/BSXyUiyNTnpYbT/a+uqCzLApVDAAASp9A Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42E1F@MX15A.corp.emc.com> References: <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> In-Reply-To: <704DAEE2-C26F-48C8-8C75-548FE115B91F@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: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/BNZ1i03puforzJ70ihWcN5JXoQY Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 16:38:57 -0000 > 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 t= hen > mark its RTCP packets like the RTP packets carrying I-frames, like the RT= P > packets carrying P-frames, or what? Answering a question w/a question :-), how are those reports likely to be u= sed? For example, if the primary use of these reports is to adjust a variable ra= te codec's sending rate, the P-frame info is probably more useful as indicativ= e of what's happening to the traffic that the network drops first when the go= ing gets rough (or whose delivery w/o loss indicates that a sending rate increa= se may be reasonable), which suggests P-frame-like RTCP report marking. Thanks, --David > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Tuesday, August 26, 2014 12:19 PM > To: Paul E. Jones > Cc: Ben Campbell; Black, David; dart@ietf.org; avt@ietf.org WG; draft-iet= f- > dart-dscp-rtp.all@tools.ietf.org > Subject: Re: Treatment of RTCP (was Re: [Dart] Colin Perkins comments - W= GLC: > draft-ietf-dart-dscp-rtp-02) >=20 > On 26 Aug 2014, at 16:52, Paul E. Jones wrote: > > Ben, > >>>>>> Getting feedback to the sender is important, though. In an ideal w= orld, > 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 id= eal > world, I don't know which DSCP value that would be. > >>>>> > >>>>> Would the starting positions of "getting feedback is important, eve= n of > not for RTT estimates" and "we need RTCP for RTT estimates" likely land o= n 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 in= to > some predictable PHB treatment. > >>>> > >>>> Good question and valid point. Nowhere in the document do we recomme= nd > the use of a particular DSCP value for any particular thing, and we shoul= d 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, m= y > suggestion would be that each SSRC mark the RTCP packets it sends with on= e 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 packe= ts it > sends. > >> > >> That makes sense to me. Paul, and others, do you agree with that last > paragraph? > > > > 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? >=20 > Such an endpoint will have three SSRC values, and will mark the RTCP pack= ets > 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 t= o the > video will be marked AF41, and the RTCP relating to the application shari= ng > video will be marked AF31. The RTCP packets for each stream are sent > separately, so this case seems straight-forward. >=20 > 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 t= hen > mark its RTCP packets like the RTP packets carrying I-frames, like the RT= P > packets carrying P-frames, or what? >=20 > Colin >=20 >=20 >=20 >=20 > > Since DSCP values cannot be assumed to any particular PHB behavior in t= he > 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 u= sed > 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 th= at > two devices would always follow the same approach to selecting a value, b= ut I > doubt we can get agreement very quickly. > > > > Paul > > >=20 >=20 >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 From nobody Tue Aug 26 22:17:23 2014 Return-Path: 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 A388B1A03ED; Tue, 26 Aug 2014 22:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 HG0ZJLQpNEEv; Tue, 26 Aug 2014 22:17:20 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD651A03E9; Tue, 26 Aug 2014 22:17:20 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s7R5HAXQ015918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 01:17:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1409116633; bh=3Qbw78wGdrCvBCpvG75oy5V1+TpbUWYlTxffbhhdvJ0=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=D1K0siknZIS+89+IAfhzwibUHuAdSJvs4g7eN4jeUaGuQyTHsTyaxkKVE8vVFGsjY 3sYM26zcFpqc6qu2c0qZx8sSb0f5/QsNMkzWxjuFiVXn/7lfeNpOT47fF6S+IeLk8p 9rcI2MJ1el3oaY0j7sHj80/uZx+oMRWExOBzJIGU= From: "Paul E. Jones" To: "Colin Perkins" Date: Wed, 27 Aug 2014 05:17:38 +0000 Message-Id: In-Reply-To: <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> User-Agent: eM_Client/6.0.20617.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dart/5SnIvZ-KWO8OWhiZceUIlODvCvI Cc: Ben Campbell , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 05:17:21 -0000 Colin, >On 26 Aug 2014, at 16:52, Paul E. Jones wrote: >> Ben, >>>>>>> Getting feedback to the sender is important, though. In an ideal= =20 >>>>>>>world, I would argue that RTCP packets should be marked with=20 >>>>>>>whatever DSCP value will deliver RTCP packets in the most=20 >>>>>>>expedient way. Since we don't have an ideal world, I don't know=20 >>>>>>>which DSCP value that would be. >>>>>> >>>>>> Would the starting positions of "getting feedback is important,=20 >>>>>>even of not for RTT estimates" and "we need RTCP for RTT=20 >>>>>>estimates" likely land on the same guidance for DSCP values? >>>>>> >>>>>> The argument to send RTCP packets in the most expedient way=20 >>>>>>sounds reasonable. I don't know if we need to recommend a=20 >>>>>>particular DSCP, since we already have quite a bit of text on how=20 >>>>>>DSCPs might (or might not) map into some predictable PHB=20 >>>>>>treatment. >>>>> >>>>> Good question and valid point. Nowhere in the document do we=20 >>>>>recommend the use of a particular DSCP value for any particular=20 >>>>>thing, and we should not recommend a particular value for RTCP in=20 >>>>>this document. I'm just not sure what statements should be made. >>>>> >>>>> I suspect we can all agree that RTCP information is important.=20 >>>>>It's just the DSCP-related guidance that goes with that that is=20 >>>>>challenging. >>>> >>>> I don=E2=80=99t agree that RTCP information should be sent as higher= =20 >>>>priority than the media. Ideally, it should be sent with the same=20 >>>>priority as the media, so it can be used to sample the RTT. This RTT= =20 >>>>sample is independent of RMCAT. It=E2=80=99s in base RTP specification,= and=20 >>>>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,= =20 >>>>my suggestion would be that each SSRC mark the RTCP packets it sends= =20 >>>>with one of the same code points as it uses to mark the media. Since= =20 >>>>RTCP is somewhat important, it would make sense for each SSRC to=20 >>>>mark the RTCP packets it sends using the highest priority code point= =20 >>>>it uses to mark the RTP media packets it sends. >>> >>> That makes sense to me. Paul, and others, do you agree with that=20 >>>last paragraph? >> >> I agree that the value should be one of the values used for media,=20 >>but the challenge is specifying which DSCP value to use. If audio is=20 >>sent using EF, video as AF41, app sharing video as AF31, etc., which=20 >>of these does the endpoint choose to use for RTCP? > >Such an endpoint will have three SSRC values, and will mark the RTCP=20 >packets sent by each SSRC in the same way as the media packets sent by=20 >that SSRC. That is, the RTCP relating to the audio will be marked EF,=20 >the RTCP relating to the video will be marked AF41, and the RTCP=20 >relating to the application sharing video will be marked AF31. The RTCP= =20 >packets for each stream are sent separately, so this case seems=20 >straight-forward. I'm a little confused here. These are separate SSRCs, but all part of a= =20 single RTP session. So, wouldn't the three SSRCs be reported in=20 different report blocks in the sender report? >The more difficult case is when an SSRC is sending video using=20 >different markings for RTP packets carrying the I- and P-frames. Should= =20 >that SSRC then mark its RTCP packets like the RTP packets carrying=20 >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=20 drop precedence (in the case of assured forwarding). Otherwise, it=20 should be the same as the media, I'd think. Paul From nobody Wed Aug 27 01:00:53 2014 Return-Path: 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 504E41A0493; Wed, 27 Aug 2014 01:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 wrUuBBoF-R-p; Wed, 27 Aug 2014 01:00:46 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D1B1A0484; Wed, 27 Aug 2014 01:00:45 -0700 (PDT) Received: from [81.187.2.149] (port=36142 helo=[192.168.0.22]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XMY9o-0000mc-8o; Wed, 27 Aug 2014 09:00:40 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Wed, 27 Aug 2014 09:00:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <44267255-BF3B-47A7-AA2C-E05633A7504B@csperkins.org> References: To: "Paul E. Jones" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/cttFvATnKrOa_A9FM1PdkwyXm3U Cc: Ben Campbell , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 08:00:52 -0000 On 27 Aug 2014, at 06:17, Paul E. Jones wrote: >> On 26 Aug 2014, at 16:52, Paul E. Jones = wrote: >>>>>>>> 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. >>>>>>>=20 >>>>>>> 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? >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> I don=92t 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=92s in base RTP specification, and so = is something we need to support to the extent possible. >>>>>=20 >>>>> 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. >>>>=20 >>>> That makes sense to me. Paul, and others, do you agree with that = last paragraph? >>>=20 >>> 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? >>=20 >> 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. >=20 > I'm a little confused here. These are separate SSRCs, but all part of = a single RTP session. So, wouldn=92t 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?=20 >> 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? >=20 > 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? --=20 Colin Perkins http://csperkins.org/ From nobody Wed Aug 27 09:01:22 2014 Return-Path: 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 0BCDE1A0B10; Wed, 27 Aug 2014 09:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 P3MJ7NQUlF9i; Wed, 27 Aug 2014 09:01:15 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFC9D1A0B0E; Wed, 27 Aug 2014 09:01:14 -0700 (PDT) Received: from [130.209.247.112] (port=52252 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XMfeo-0001p0-SM; Wed, 27 Aug 2014 17:01:11 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BB42E1F@MX15A.corp.emc.com> Date: Wed, 27 Aug 2014 17:00:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <22E25F9C-E9B1-4C3C-989E-570BAAF58018@csperkins.org> References: <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> <8D3D17ACE214DC429325B2B98F3AE712077BB42E1F@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/N2boZ4sC2svLq6qZ1HCCIrjmTkw Cc: "Paul E. Jones" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 16:01:17 -0000 On 26 Aug 2014, at 17:38, Black, David wrote: >> 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? >=20 > Answering a question w/a question :-), how are those reports likely to = be used? >=20 > 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. I doubt the RTT estimate derived from RTCP is used for congestion = control, since it=92s too infrequent to get insight into the dynamics. = It=92s for user experience reporting, maybe rough clustering of = receivers, that sort of thing.=20 --=20 Colin Perkins http://csperkins.org/ From nobody Wed Aug 27 11:39:38 2014 Return-Path: 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 AC82A1A00FE; Wed, 27 Aug 2014 11:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 mJCB22RupGkn; Wed, 27 Aug 2014 11:39:34 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A0C1A019C; Wed, 27 Aug 2014 11:39:33 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XMi82-0000XP-CB; Wed, 27 Aug 2014 20:39:30 +0200 Received: from 25.71.202.84.customer.cdi.no ([84.202.71.25] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1XMi81-0002B8-RR; Wed, 27 Aug 2014 20:39:30 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <22E25F9C-E9B1-4C3C-989E-570BAAF58018@csperkins.org> Date: Wed, 27 Aug 2014 20:39:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> <8D3D17ACE214DC429325B2B98F3AE712077BB42E1F@MX15A.corp.emc.com> <22E25F9C-E9B1-4C3C-989E-570BAAF58018@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 12 sum msgs/h 4 total rcpts 19570 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8C2E7AF0E8135D8B7E39A1A592E5EE226832A8A7 X-UiO-SPAM-Test: remote_host: 84.202.71.25 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 179 max/h 7 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/KcGtqN8RvozCB14kRBRoQnSfja8 Cc: "Paul E. Jones" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 18:39:37 -0000 On 27. aug. 2014, at 18:00, Colin Perkins wrote: > On 26 Aug 2014, at 17:38, Black, David wrote: >>> 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? >>=20 >> Answering a question w/a question :-), how are those reports likely = to be used? >>=20 >> 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. >=20 > I doubt the RTT estimate derived from RTCP is used for congestion = control, since it=92s too infrequent to get insight into the dynamics. = It=92s for user experience reporting, maybe rough clustering of = receivers, that sort of thing.=20 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 nobody Wed Aug 27 11:42:52 2014 Return-Path: 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 954571A6EED; Wed, 27 Aug 2014 11:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Nb8v6jXfe1dv; Wed, 27 Aug 2014 11:42:46 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E171A014A; Wed, 27 Aug 2014 11:42:46 -0700 (PDT) Received: from [81.187.2.149] (port=36736 helo=[192.168.0.22]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XMiB9-0005PO-8E; Wed, 27 Aug 2014 19:42:43 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Wed, 27 Aug 2014 19:42:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1B4C6B70-B3EB-45C0-892D-328954E3AD4E@csperkins.org> References: <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> <8D3D17ACE214DC429325B2B98F3AE712077BB42E1F@MX15A.corp.emc.com> <22E25F9C-E9B1-4C3C-989E-570BAAF58018@csperkins.org> To: Michael Welzl X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/aJrFjMnMTTslSab8SYg7PRcMHOc Cc: "Paul E. Jones" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 18:42:48 -0000 On 27 Aug 2014, at 19:39, Michael Welzl wrote: > On 27. aug. 2014, at 18:00, Colin Perkins wrote: >> On 26 Aug 2014, at 17:38, Black, David wrote: >>>> 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? >>>=20 >>> Answering a question w/a question :-), how are those reports likely = to be used? >>>=20 >>> 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. >>=20 >> I doubt the RTT estimate derived from RTCP is used for congestion = control, since it=92s too infrequent to get insight into the dynamics. = It=92s for user experience reporting, maybe rough clustering of = receivers, that sort of thing.=20 >=20 > 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=92d 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. --=20 Colin Perkins http://csperkins.org/ From nobody Wed Aug 27 11:47:12 2014 Return-Path: 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 0C3C51A007D; Wed, 27 Aug 2014 11:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 ufcLNKelW1JC; Wed, 27 Aug 2014 11:47:08 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B581A6F0C; Wed, 27 Aug 2014 11:47:08 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XMiFN-00016X-GY; Wed, 27 Aug 2014 20:47:05 +0200 Received: from 25.71.202.84.customer.cdi.no ([84.202.71.25] helo=[192.168.0.114]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1XMiFM-0000Jk-Kj; Wed, 27 Aug 2014 20:47:05 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_B0CEE16D-C655-4D5C-A948-D1AB874731FD" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <1B4C6B70-B3EB-45C0-892D-328954E3AD4E@csperkins.org> Date: Wed, 27 Aug 2014 20:47:03 +0200 Message-Id: References: <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> <8D3D17ACE214DC429325B2B98F3AE712077BB42E1F@MX15A.corp.emc.com> <22E25F9C-E9B1-4C3C-989E-570BAAF58018@csperkins.org> <1B4C6B70-B3EB-45C0-892D-328954E3AD4E@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 13 msgs/h 3 sum rcpts/h 18 sum msgs/h 5 total rcpts 19576 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 82E6BEA8F050D04A54E242733969D6EB6CC4B95A X-UiO-SPAM-Test: remote_host: 84.202.71.25 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 180 max/h 7 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/xwkPxTw0j_qoLpcC26YnhvIOu7I Cc: "Paul E. Jones" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 18:47:10 -0000 --Apple-Mail=_B0CEE16D-C655-4D5C-A948-D1AB874731FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 27. aug. 2014, at 20:42, Colin Perkins wrote: > On 27 Aug 2014, at 19:39, Michael Welzl wrote: >> On 27. aug. 2014, at 18:00, Colin Perkins wrote: >>> On 26 Aug 2014, at 17:38, Black, David wrote: >>>>> 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? >>>>=20 >>>> Answering a question w/a question :-), how are those reports likely = to be used? >>>>=20 >>>> 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. >>>=20 >>> I doubt the RTT estimate derived from RTCP is used for congestion = control, since it=92s too infrequent to get insight into the dynamics. = It=92s for user experience reporting, maybe rough clustering of = receivers, that sort of thing.=20 >>=20 >> 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? >=20 > I=92d 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. 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 --Apple-Mail=_B0CEE16D-C655-4D5C-A948-D1AB874731FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 27. aug. 2014, at 20:42, Colin = Perkins <csp@csperkins.org>= wrote:

On 27 Aug 2014, at 19:39, Michael = Welzl <michawe@ifi.uio.no>= wrote:
On 27. aug. 2014, at 18:00, Colin = Perkins <csp@csperkins.org>= wrote:
On 26 Aug 2014, at 17:38, Black, = David <david.black@emc.com> = wrote:
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.

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

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=92d 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.

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

= --Apple-Mail=_B0CEE16D-C655-4D5C-A948-D1AB874731FD-- From nobody Wed Aug 27 11:50:33 2014 Return-Path: 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 6EF611A00F5; Wed, 27 Aug 2014 11:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 RLV6ZthwqWkn; Wed, 27 Aug 2014 11:50:28 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2621A00DD; Wed, 27 Aug 2014 11:50:28 -0700 (PDT) Received: from [81.187.2.149] (port=39485 helo=[192.168.0.22]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XMiIa-00066D-9l; Wed, 27 Aug 2014 19:50:25 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_C67B8F62-80F6-47E2-8469-2AFB250D77B7" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Wed, 27 Aug 2014 19:50:22 +0100 Message-Id: <0F1C9E57-EDA5-4A44-9F8A-87A76C159AED@csperkins.org> References: <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> <8D3D17ACE214DC429325B2B98F3AE712077BB42E1F@MX15A.corp.emc.com> <22E25F9C-E9B1-4C3C-989E-570BAAF58018@csperkins.org> <1B4C6B70-B3EB-45C0-892D-328954E3AD4E@csperkins.org> To: Michael Welzl X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/O-7LLnW18JLa7jNwrUiNDfwt6dY Cc: "Paul E. Jones" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 18:50:30 -0000 --Apple-Mail=_C67B8F62-80F6-47E2-8469-2AFB250D77B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 27 Aug 2014, at 19:47, Michael Welzl wrote: > On 27. aug. 2014, at 20:42, Colin Perkins wrote: >> On 27 Aug 2014, at 19:39, Michael Welzl wrote: >>> On 27. aug. 2014, at 18:00, Colin Perkins wrote: >>>> On 26 Aug 2014, at 17:38, Black, David wrote: >>>>>> 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? >>>>>=20 >>>>> Answering a question w/a question :-), how are those reports = likely to be used? >>>>>=20 >>>>> 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. >>>>=20 >>>> I doubt the RTT estimate derived from RTCP is used for congestion = control, since it=92s too infrequent to get insight into the dynamics. = It=92s for user experience reporting, maybe rough clustering of = receivers, that sort of thing.=20 >>>=20 >>> 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? >>=20 >> I=92d 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. >=20 > 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. You have the RTT estimate, irrespective of the other information you = include along with the regular RTCP packets, although it=92s relatively = infrequent and coarse-grained. > I wonder if your RTCP draft in RMCAT should clarify this? (sorry if = it does already, didn=92t check) It probably should talk about this, I agree. --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_C67B8F62-80F6-47E2-8469-2AFB250D77B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On 27 = Aug 2014, at 19:47, Michael Welzl <michawe@ifi.uio.no> = wrote:
On 27. aug. 2014, at 20:42, Colin Perkins = <csp@csperkins.org> = wrote:
On 27 = Aug 2014, at 19:39, Michael Welzl <michawe@ifi.uio.no> = wrote:
On 27. aug. 2014, at 18:00, Colin = Perkins <csp@csperkins.org>= wrote:
On 26 Aug 2014, at 17:38, Black, = David <david.black@emc.com> = wrote:
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.

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

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=92d 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.

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.

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

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

It probably should talk = about this, I agree.


-- 
Colin Perkins



= --Apple-Mail=_C67B8F62-80F6-47E2-8469-2AFB250D77B7-- From nobody Wed Aug 27 12:46:34 2014 Return-Path: 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 3438C1A01BD for ; Wed, 27 Aug 2014 12:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=unavailable 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 h7jrBkdbRgzi for ; Wed, 27 Aug 2014 12:46:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DCA1A0180 for ; Wed, 27 Aug 2014 12:46:31 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7RJkNTx046739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 14:46:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <0F1C9E57-EDA5-4A44-9F8A-87A76C159AED@csperkins.org> Date: Wed, 27 Aug 2014 14:46:21 -0500 X-Mao-Original-Outgoing-Id: 430861581.373023-2e4bfa5c03b5c80373e7a52ec9c305c0 Content-Transfer-Encoding: quoted-printable Message-Id: References: <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> <8D3D17ACE214DC429325B2B98F3AE712077BB42E1F@MX15A.corp.emc.com> <22E25F9C-E9B1-4C3C-989E-570BAAF58018@csperkins.org> <1B4C6B70-B3EB-45C0-892D-328954E3AD4E@csperkins.org> <0F1C9E57-EDA5-4A44-9F8A-87A76C159AED@csperkins.org> To: Colin Perkins , "Black, David" , "Paul E. Jones" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/OvEUtuI16EJ_nR1yEu7YPlVedVc Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , "avt@ietf.org WG" , Michael Welzl Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 19:46:33 -0000 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 wrote: > On 27 Aug 2014, at 19:47, Michael Welzl wrote: >> On 27. aug. 2014, at 20:42, Colin Perkins wrote: >>> On 27 Aug 2014, at 19:39, Michael Welzl wrote: >>>> On 27. aug. 2014, at 18:00, Colin Perkins = wrote: >>>>> On 26 Aug 2014, at 17:38, Black, David = wrote: >>>>>>> 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? >>>>>>=20 >>>>>> Answering a question w/a question :-), how are those reports = likely to be used? >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> I doubt the RTT estimate derived from RTCP is used for congestion = control, since it=92s too infrequent to get insight into the dynamics. = It=92s for user experience reporting, maybe rough clustering of = receivers, that sort of thing.=20 >>>>=20 >>>> 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? >>>=20 >>> I=92d 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. >>=20 >> 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. >=20 > You have the RTT estimate, irrespective of the other information you = include along with the regular RTCP packets, although it=92s relatively = infrequent and coarse-grained. >=20 >> I wonder if your RTCP draft in RMCAT should clarify this? (sorry if = it does already, didn=92t check) >=20 > It probably should talk about this, I agree. >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Wed Aug 27 13:45:20 2014 Return-Path: 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 321C71A02E0; Wed, 27 Aug 2014 13:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 BRalJ7XVLoKU; Wed, 27 Aug 2014 13:45:15 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C523F1A0282; Wed, 27 Aug 2014 13:45:14 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XMk5c-0003xh-3U; Wed, 27 Aug 2014 22:45:08 +0200 Received: from 25.71.202.84.customer.cdi.no ([84.202.71.25] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1XMk5b-0005py-Ev; Wed, 27 Aug 2014 22:45:08 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Wed, 27 Aug 2014 22:45:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> <8D3D17ACE214DC429325B2B98F3AE712077BB42E1F@MX15A.corp.emc.com> <22E25F9C-E9B1-4C3C-989E-570BAAF58018@csperkins.org> <1B4C6B70-B3EB-45C0-892D-328954E3AD4E@csperkins.org> <0F1C9E57-EDA5-4A44-9F8A-87A76C159AED@csperkins.org> To: Ben Campbell X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 1 sum rcpts/h 13 sum msgs/h 3 total rcpts 19588 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 13D793E7B1647186306EA8C4C19AA58E771DDB83 X-UiO-SPAM-Test: remote_host: 84.202.71.25 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 184 max/h 7 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/8Fnk2-37APEQU53TLru8jlSexKM Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "Paul E. Jones" , Colin Perkins Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 20:45:18 -0000 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 On 27. aug. 2014, at 21:46, Ben Campbell wrote: > Hi, >=20 > Where are we with this discussion? Are there conclusions buried in = there somewhere? >=20 > Thanks! >=20 > Ben. >=20 > On Aug 27, 2014, at 1:50 PM, Colin Perkins wrote: >=20 >> On 27 Aug 2014, at 19:47, Michael Welzl wrote: >>> On 27. aug. 2014, at 20:42, Colin Perkins wrote: >>>> On 27 Aug 2014, at 19:39, Michael Welzl wrote: >>>>> On 27. aug. 2014, at 18:00, Colin Perkins = wrote: >>>>>> On 26 Aug 2014, at 17:38, Black, David = wrote: >>>>>>>> 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? >>>>>>>=20 >>>>>>> Answering a question w/a question :-), how are those reports = likely to be used? >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> I doubt the RTT estimate derived from RTCP is used for congestion = control, since it=92s too infrequent to get insight into the dynamics. = It=92s for user experience reporting, maybe rough clustering of = receivers, that sort of thing.=20 >>>>>=20 >>>>> 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? >>>>=20 >>>> I=92d 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. >>>=20 >>> 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. >>=20 >> You have the RTT estimate, irrespective of the other information you = include along with the regular RTCP packets, although it=92s relatively = infrequent and coarse-grained. >>=20 >>> I wonder if your RTCP draft in RMCAT should clarify this? (sorry if = it does already, didn=92t check) >>=20 >> It probably should talk about this, I agree. >>=20 >>=20 >> --=20 >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >>=20 >> _______________________________________________ >> Dart mailing list >> Dart@ietf.org >> https://www.ietf.org/mailman/listinfo/dart >=20 From nobody Wed Aug 27 13:48:49 2014 Return-Path: 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 CFE321A026A for ; Wed, 27 Aug 2014 13:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=unavailable 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 oilcmNUlj2xb for ; Wed, 27 Aug 2014 13:48:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140F61A0180 for ; Wed, 27 Aug 2014 13:48:46 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7RKmdbJ052568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 15:48:40 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Wed, 27 Aug 2014 15:48:37 -0500 X-Mao-Original-Outgoing-Id: 430865317.29984-1c72e872c3149930929f43a22d66b9e2 Content-Transfer-Encoding: quoted-printable Message-Id: References: <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> <8D3D17ACE214DC429325B2B98F3AE712077BB42E1F@MX15A.corp.emc.com> <22E25F9C-E9B1-4C3C-989E-570BAAF58018@csperkins.org> <1B4C6B70-B3EB-45C0-892D-328954E3AD4E@csperkins.org> <0F1C9E57-EDA5-4A44-9F8A-87A76C159AED@csperkins.org> To: Michael Welzl , Colin Perkins , "Paul E. Jones" , "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/dw-mGxneHA4p85373jMTcKn_Cug 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) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 20:48:47 -0000 On Aug 27, 2014, at 3:45 PM, Michael Welzl wrote: > I don't know the beginning of this but I can help go up the stack: >=20 > 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. >=20 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 nobody Wed Aug 27 14:41:49 2014 Return-Path: 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 914EA1A0052; Wed, 27 Aug 2014 14:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.06 X-Spam-Level: X-Spam-Status: No, score=-1.06 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 gepPyyz--V8j; Wed, 27 Aug 2014 14:41:37 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD55C1A003B; Wed, 27 Aug 2014 14:41:36 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s7RLfOBq014606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 17:41:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1409175685; bh=HPrK2AO2j7hypRTgQ+tlOnJz0GIQ+skB4ThnZmxSiz0=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=cpWboXhne69DXsR8fyeGJGtjvM5iO8nykL9ugjQGWUtmfsl/S7wtR8nRkOTrlmegJ 6+1wxCp5J/pIU9Gm+HBgjov5Nl0Y6l/Jr9bL4nf8/jDma6Bm7cVxilUAuci5DogwgP yBLHj5QjTxDY2/Ync6w70+le9AF+Bq6pZe0NBNsk= From: "Paul E. Jones" To: "Colin Perkins" Date: Wed, 27 Aug 2014 21:41:53 +0000 Message-Id: In-Reply-To: <44267255-BF3B-47A7-AA2C-E05633A7504B@csperkins.org> User-Agent: eM_Client/6.0.20617.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dart/50SK71J25lDPDoZC5b1PFHyqPKU Cc: Ben Campbell , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 21:41:39 -0000 Colin >>>> I agree that the value should be one of the values used for media,= =20 >>>>but the challenge is specifying which DSCP value to use. If audio is= =20 >>>>sent using EF, video as AF41, app sharing video as AF31, etc., which= =20 >>>>of these does the endpoint choose to use for RTCP? >>> >>> Such an endpoint will have three SSRC values, and will mark the RTCP= =20 >>>packets sent by each SSRC in the same way as the media packets sent=20 >>>by that SSRC. That is, the RTCP relating to the audio will be marked=20 >>>EF, the RTCP relating to the video will be marked AF41, and the RTCP=20 >>>relating to the application sharing video will be marked AF31. The=20 >>>RTCP packets for each stream are sent separately, so this case seems=20 >>>straight-forward. >> >> I'm a little confused here. These are separate SSRCs, but all part of= =20 >>a single RTP session. So, wouldn=E2=80=99t the three SSRCs be reported= in=20 >>different report blocks in the sender report? > >Each of the SSRCs will report on all the others, unless the=20 >rtp-multi-stream-optimisation draft is used, but so what? Oh, I think I understand what you are saying. You're saying that each=20 media flow (SSRC) would be responsible for sending its own RTCP packets=20 and those packets would be marked in the same way as that media flow. =20 In that case, I agree with you. That said, would we really require the sending SSRC to include any data=20 for the other SSRCs if they're each sending RTCP packets separately? =20 That seems redundant. Does RFC 3550 require that? (It's been a=20 while...) >>> The more difficult case is when an SSRC is sending video using=20 >>>different markings for RTP packets carrying the I- and P-frames.=20 >>>Should that SSRC then mark its RTCP packets like the RTP packets=20 >>>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= =20 >>drop precedence (in the case of assured forwarding). Otherwise, it=20 >>should be the same as the media, I'd think. > >You mean the RTCP for each SSRC should use the DSCP with the lowest=20 >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=20 for RTCP. I suggest that, since I assume we don't want to lose feedback= =20 information if we can avoid it. Paul From nobody Wed Aug 27 15:52:40 2014 Return-Path: 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 C7B1F1A01D2; Wed, 27 Aug 2014 15:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 lT6yhEqvH8X7; Wed, 27 Aug 2014 15:52:30 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A791A0278; Wed, 27 Aug 2014 15:52:30 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s7RMqK3f019069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 18:52:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1409179942; bh=uIk9p5Qw7hGYam+MxvWD43G7pTlb+B+QjKqukc11vJM=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=BQGSZGoqva/799Tksfxqyjpasy4VW81X0tl6SYAhjxGT+M6oM0ZnrtPquz2mqOTu4 VIsm5i6T3go/U7aONHuzFtxzPQUdgc1wSvformGhS0IBml905eGNIUTieVv6ZuPjgT BLV1GCncpBJDzpJOwq1tzPk4cLyqxtdTU5W9x2aY= From: "Paul E. Jones" To: "Ben Campbell" , "Michael Welzl" , "Colin Perkins" , "Black, David" Date: Wed, 27 Aug 2014 22:52:49 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.20617.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dart/BSO9VWgcFM2xBO64LtoRoLzVuEQ 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) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 22:52:32 -0000 RTCP might not be used for RTT calculations (it might; I just doubt it's= =20 terribly useful), but RTCP might be used to convey QoE measurements or=20 one-way delay information useful for RMCAT. I think there is agreement that the DSCP value applied to the RTCP=20 packet for a given SSRC sender should align with the DSCP value used for= =20 the corresponding RTP packets of that sender. In the case where an AFxx=20 class is used, I'm not sure there is agreement (though no disagreement).= =20 I stated my view that we should use the lowest drop precedence in that= =20 case, but others should weigh in. Paul ------ Original Message ------ From: "Ben Campbell" To: "Michael Welzl" ; "Colin Perkins"=20 ; "Paul E. Jones" ; "Black,=20 David" Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org"=20 ; "dart@ietf.org"=20 ; "avt@ietf.org WG" Sent: 8/27/2014 4:48:37 PM Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin Perkins=20 comments - WGLC: draft-ietf-dart-dscp-rtp-02) >On Aug 27, 2014, at 3:45 PM, Michael Welzl 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= =20 >>is right. RTCP probably won't be used by congestion control to=20 >>estimate the RTT. >> > >Thanks, Michael, I think that fits with some earlier conversations as=20 >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 From nobody Wed Aug 27 18:59:06 2014 Return-Path: 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 D86F51A0089; Wed, 27 Aug 2014 18:59:04 -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 cB5hbEcuRV1b; Wed, 27 Aug 2014 18:59:02 -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 A342B1A00A5; Wed, 27 Aug 2014 18:59:00 -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 s7S1wprX004930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Aug 2014 21:58:52 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7S1wprX004930 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409191132; bh=qfilAdVKVlqK03k3uGOyvw1rcIU=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=xHKPv40SXRxbum02uLvXZRMS+Gmk+Z+khS4g5pzWJ6B11mC95cWkr1F0LXvuEc1AB G2KNF1tf8r6G2+Bb3SdQndFlvWjJJGhjLs4LTJDbo7PcMS4OEx8w+VeX2YHgvZ8uBs h0ghT1Q0crEA4hbBbiZeWLLMB9xo3nINlwoAndVY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7S1wprX004930 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 27 Aug 2014 21:58:37 -0400 Received: from mxhub37.corp.emc.com (mxhub37.corp.emc.com [128.222.70.104]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7S1waeC030331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Aug 2014 21:58:36 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Wed, 27 Aug 2014 21:58:36 -0400 From: "Black, David" To: "Paul E. Jones" , Ben Campbell , Michael Welzl , Colin Perkins Date: Wed, 27 Aug 2014 21:58:34 -0400 Thread-Topic: Treatment of RTCP - proposed text Thread-Index: Ac/CY5Np9OQoThvRR+WsroEF6xAxkw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB4310B@MX15A.corp.emc.com> 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: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/hqD0TFFlSb3Ph8Y-cjQT7_TwTeU Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: [Dart] Treatment of RTCP - proposed text X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 01:59:05 -0000 VHJ5aW5nIHRvIHByb3Bvc2Ugc29tZSB0ZXh0IGhlcmU6DQoNCk9MRA0KICAgbyAgU2hvdWxkIHVz ZSBhIHNpbmdsZSBEU0NQIGZvciBhbiBSVENQIHNlc3Npb24sIHByaW1hcmlseSB0byBhdm9pZA0K ICAgICAgUlRDUCByZW9yZGVyaW5nIChhbmQgYmVjYXVzZSB0aGVyZSBpcyBubyBjb21wZWxsaW5n IHJlYXNvbiBmb3IgdXNlDQogICAgICBvZiBkaWZmZXJlbnQgZHJvcCBwcmVjZWRlbmNlcykuICBP bmUgb2YgdGhlIFBIQnMgYW5kIGFzc29jaWF0ZWQNCiAgICAgIERTQ1AgdXNlZCBmb3IgdGhlIGFz c29jaWF0ZWQgUlRQIHRyYWZmaWMgd291bGQgYmUgYW4gYXBwcm9wcmlhdGUNCiAgICAgIGNob2lj ZS4gIFtFZGl0b3IncyBub3RlOiBUaGlzIGJ1bGxldCBpcyBhbiBvcGVuIHRlY2huaWNhbCBpc3N1 ZS5dDQpORVcNCiAgIG8gIFNob3VsZCB1c2UgdGhlIHNhbWUgRFNDUCBmb3IgUlRDUCByZXBvcnRz IGFzIHVzZWQgZm9yIHRoZSBSVFAgc3RyZWFtDQogICAgICB0aGF0IGlzIGJlaW5nIHJlcG9ydGVk IG9uIHdoZW4gdGhhdCBEU0NQIGlzIGtub3duIGJ5IHRoZSBSVENQIHNlbmRlci4NCiAgICAgIFdo ZW4gYW4gUlRQIHN0cmVhbSB1c2VzIG11bHRpcGxlIERTQ1BzIHRoYXQgZGlmZmVyIG9ubHkgaW4g ZHJvcA0KICAgICAgcHJlY2VkZW5jZSwgUlRDUCByZXBvcnRzIG9uIHRoYXQgUlRQIHN0cmVhbSBz aG91bGQgdXNlIHRoZSBEU0NQIHdpdGgNCiAgICAgIHRoZSBsZWFzdCBsaWtlbGlob29kIG9mIGRy b3AgdG8gZmF2b3IgZGVsaXZlcnkgb2YgdGhlIFJUQ1AgcmVwb3J0cy4NCiAgICAgIFdoZW4gYSBz aW5nbGUgUlRDUCBtZXNzYWdlIHJlcG9ydHMgb24gbXVsdGlwbGUgUlRQIHN0cmVhbXMgdGhhdA0K ICAgICAgYXJlIHNlbnQgd2l0aCBkaWZmZXJlbnQgRFNDUHMsIHRoZSBSVENQIHNlbmRlciBzaG91 bGQgY2hvb3NlIG9uZQ0KICAgICAgb2YgdGhvc2UgRFNDUHMuICBXaGVuIHRoZSBSVENQIHNlbmRl ciBkb2VzIG5vdCBrbm93IHdoYXQNCglEU0NQIG9yIERTQ1BzIHdlcmUgdXNlZCB0byBzZW5kIGFu IFJUUCBzdHJlYW0sIGl0IHNob3VsZCBjaG9vc2UNCglhIERTQ1AgdGhhdCBpdCB3b3VsZCB1c2Ug dG8gc2VuZCBhIHNpbWlsYXIgUlRQIHN0cmVhbS4NCiAgICAgIA0KVGhlIGxhdHRlciBzZW50ZW5j ZSBpcyBjb3VydGVzeSBvZiB0aGUgZmFjdCB0aGF0IHRoZXJlIHdpbGwgYmUgY2FzZXMNCndoZXJl IHRoZSBSVENQIHNlbmRlciB3aWxsIG5vdCBrbm93IHdoYXQgRFNDUCBvciBEU0NQcyB3ZXJlIHVz ZWQgdG8gc2VuZA0KdGhlIFJUUCBzdHJlYW0sIGR1ZSB0byBlbi1yb3V0ZSByZW1hcmtpbmcuDQoN CklmIHRoYXQgdGV4dCBsb29rcyBjbG9zZSwgSSdsbCBlZGl0IGZ1cnRoZXIgYW5kIHRyeSB0byBn ZXQgdGhlIC0wNSBzdWJtaXR0ZWQNCmJ5IHRoZSBlbmQgb2YgdGhpcyB3ZWVrLg0KDQpUaGFua3Ms DQotLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGF1bCBF LiBKb25lcyBbbWFpbHRvOnBhdWxlakBwYWNrZXRpemVyLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5 LCBBdWd1c3QgMjcsIDIwMTQgNjo1MyBQTQ0KPiBUbzogQmVuIENhbXBiZWxsOyBNaWNoYWVsIFdl bHpsOyBDb2xpbiBQZXJraW5zOyBCbGFjaywgRGF2aWQNCj4gQ2M6IGRyYWZ0LWlldGYtZGFydC1k c2NwLXJ0cC5hbGxAdG9vbHMuaWV0Zi5vcmc7IGRhcnRAaWV0Zi5vcmc7IGF2dEBpZXRmLm9yZw0K PiBXRw0KPiBTdWJqZWN0OiBSZTogW0RhcnRdIFtBVlRDT1JFXSBUcmVhdG1lbnQgb2YgUlRDUCAo d2FzIFJlOiBDb2xpbiBQZXJraW5zDQo+IGNvbW1lbnRzIC0gV0dMQzogZHJhZnQtaWV0Zi1kYXJ0 LWRzY3AtcnRwLTAyKQ0KPiANCj4gUlRDUCBtaWdodCBub3QgYmUgdXNlZCBmb3IgUlRUIGNhbGN1 bGF0aW9ucyAoaXQgbWlnaHQ7IEkganVzdCBkb3VidCBpdCdzDQo+IHRlcnJpYmx5IHVzZWZ1bCks ICBidXQgUlRDUCBtaWdodCBiZSB1c2VkIHRvIGNvbnZleSBRb0UgbWVhc3VyZW1lbnRzIG9yDQo+ IG9uZS13YXkgZGVsYXkgaW5mb3JtYXRpb24gdXNlZnVsIGZvciBSTUNBVC4NCj4gDQo+IEkgdGhp bmsgdGhlcmUgaXMgYWdyZWVtZW50IHRoYXQgdGhlIERTQ1AgdmFsdWUgYXBwbGllZCB0byB0aGUg UlRDUA0KPiBwYWNrZXQgZm9yIGEgZ2l2ZW4gU1NSQyBzZW5kZXIgc2hvdWxkIGFsaWduIHdpdGgg dGhlIERTQ1AgdmFsdWUgdXNlZCBmb3INCj4gdGhlIGNvcnJlc3BvbmRpbmcgUlRQIHBhY2tldHMg b2YgdGhhdCBzZW5kZXIuIEluIHRoZSBjYXNlIHdoZXJlIGFuIEFGeHgNCj4gY2xhc3MgaXMgdXNl ZCwgSSdtIG5vdCBzdXJlIHRoZXJlIGlzIGFncmVlbWVudCAodGhvdWdoIG5vIGRpc2FncmVlbWVu dCkuDQo+ICAgSSBzdGF0ZWQgbXkgdmlldyB0aGF0IHdlIHNob3VsZCB1c2UgdGhlIGxvd2VzdCBk cm9wIHByZWNlZGVuY2UgaW4gdGhhdA0KPiBjYXNlLCBidXQgb3RoZXJzIHNob3VsZCB3ZWlnaCBp bi4NCj4gDQo+IFBhdWwNCj4gDQo+IC0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLQ0KPiBG cm9tOiAiQmVuIENhbXBiZWxsIiA8YmVuQG5vc3RydW0uY29tPg0KPiBUbzogIk1pY2hhZWwgV2Vs emwiIDxtaWNoYXdlQGlmaS51aW8ubm8+OyAiQ29saW4gUGVya2lucyINCj4gPGNzcEBjc3Blcmtp bnMub3JnPjsgIlBhdWwgRS4gSm9uZXMiIDxwYXVsZWpAcGFja2V0aXplci5jb20+OyAiQmxhY2ss DQo+IERhdmlkIiA8ZGF2aWQuYmxhY2tAZW1jLmNvbT4NCj4gQ2M6ICJkcmFmdC1pZXRmLWRhcnQt ZHNjcC1ydHAuYWxsQHRvb2xzLmlldGYub3JnIg0KPiA8ZHJhZnQtaWV0Zi1kYXJ0LWRzY3AtcnRw LmFsbEB0b29scy5pZXRmLm9yZz47ICJkYXJ0QGlldGYub3JnIg0KPiA8ZGFydEBpZXRmLm9yZz47 ICJhdnRAaWV0Zi5vcmcgV0ciIDxhdnRAaWV0Zi5vcmc+DQo+IFNlbnQ6IDgvMjcvMjAxNCA0OjQ4 OjM3IFBNDQo+IFN1YmplY3Q6IFJlOiBbRGFydF0gW0FWVENPUkVdIFRyZWF0bWVudCBvZiBSVENQ ICh3YXMgUmU6IENvbGluIFBlcmtpbnMNCj4gY29tbWVudHMgLSBXR0xDOiBkcmFmdC1pZXRmLWRh cnQtZHNjcC1ydHAtMDIpDQo+IA0KPiA+T24gQXVnIDI3LCAyMDE0LCBhdCAzOjQ1IFBNLCBNaWNo YWVsIFdlbHpsIDxtaWNoYXdlQGlmaS51aW8ubm8+IHdyb3RlOg0KPiA+DQo+ID4+ICBJIGRvbid0 IGtub3cgdGhlIGJlZ2lubmluZyBvZiB0aGlzIGJ1dCBJIGNhbiBoZWxwIGdvIHVwIHRoZSBzdGFj azoNCj4gPj4NCj4gPj4gIGZvciB0aGUgc2hvcnQgZGlhbG9ndWUgYmV0d2VlbiBDb2xpbiBhbmQg bWUsIHRoZSBjb25jbHVzaW9uIGlzOiBDb2xpbg0KPiA+PmlzIHJpZ2h0LiBSVENQIHByb2JhYmx5 IHdvbid0IGJlIHVzZWQgYnkgY29uZ2VzdGlvbiBjb250cm9sIHRvDQo+ID4+ZXN0aW1hdGUgdGhl IFJUVC4NCj4gPj4NCj4gPg0KPiA+VGhhbmtzLCBNaWNoYWVsLCBJIHRoaW5rIHRoYXQgZml0cyB3 aXRoIHNvbWUgZWFybGllciBjb252ZXJzYXRpb25zIGFzDQo+ID53ZWxsLg0KPiA+DQo+ID5Db2xp biBhbmQgUGF1bCAoYW5kIERhdmlkKToNCj4gPg0KPiA+QXJlIHdlIGNvbnZlcmdpbmcgb24gd2hh dCBndWlkYW5jZSB0byBwdXQgaW50byB0aGUgREFSVCBkcmFmdD8NCj4gPg0KPiA+VGhhbmtzIQ0K PiA+DQo+ID5CZW4uDQo+ID4NCj4gPg0KPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPkRhcnQgbWFpbGluZyBsaXN0DQo+ID5EYXJ0QGlldGYub3Jn DQo+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RhcnQNCg0K From nobody Wed Aug 27 19:28:19 2014 Return-Path: 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 D7D2E1A0251 for ; Wed, 27 Aug 2014 19:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=unavailable 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 nnd1DvKwD9MV for ; Wed, 27 Aug 2014 19:28:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677C41A023F for ; Wed, 27 Aug 2014 19:28:14 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7S2S7JV086104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 21:28:08 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BB4310B@MX15A.corp.emc.com> Date: Wed, 27 Aug 2014 21:28:07 -0500 X-Mao-Original-Outgoing-Id: 430885687.048631-44d5d90b2c90e10ee83010a9c4d478a7 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712077BB4310B@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/n6nAP2H5B4xxmbmNlUiWHDDkL18 Cc: Michael Welzl , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , "avt@ietf.org WG" , "Paul E. Jones" , Colin Perkins Subject: Re: [Dart] Treatment of RTCP - proposed text X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 02:28:17 -0000 I do not object to the text per se.=20 But I do have a bit of a nagging concern that we may be offering too = strong of guidance, given the thought process so far. Do we believe we = understand this well enough to say the sender should to this or that, as = opposed to say that these are things the implementer should think about, = and that these are probably reasonable choices?=20 Is this an area where we need more deployment experience to offer real = guidance? (I think it's okay for the doc to say that, if needed.) But in any case, I will defer to Colin, Paul, and David. On Aug 27, 2014, at 8:58 PM, Black, David wrote: > Trying to propose some text here: >=20 > 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. >=20 > 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. >=20 > If that text looks close, I'll edit further and try to get the -05 = submitted > by the end of this week. >=20 > Thanks, > --David >=20 >> -----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) >>=20 >> 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. >>=20 >> 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. >>=20 >> Paul >>=20 >> ------ Original Message ------ >> From: "Ben Campbell" >> To: "Michael Welzl" ; "Colin Perkins" >> ; "Paul E. Jones" ; "Black, >> David" >> Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" >> ; "dart@ietf.org" >> ; "avt@ietf.org WG" >> 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) >>=20 >>> On Aug 27, 2014, at 3:45 PM, Michael Welzl = wrote: >>>=20 >>>> I don't know the beginning of this but I can help go up the stack: >>>>=20 >>>> 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. >>>>=20 >>>=20 >>> Thanks, Michael, I think that fits with some earlier conversations = as >>> well. >>>=20 >>> Colin and Paul (and David): >>>=20 >>> Are we converging on what guidance to put into the DART draft? >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>>=20 >>> _______________________________________________ >>> Dart mailing list >>> Dart@ietf.org >>> https://www.ietf.org/mailman/listinfo/dart >=20 From nobody Wed Aug 27 20:13:52 2014 Return-Path: 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 CAFEC1A02F5; Wed, 27 Aug 2014 20:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 5oMM3bBNRdBj; Wed, 27 Aug 2014 20:13:38 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF5C1A00D5; Wed, 27 Aug 2014 20:13:38 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s7S3DONb002840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 23:13:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1409195605; bh=UwTDB5+k8gSLY7JsGxFffQ0N0vhfMdx5JvD4oxFDzGM=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=p4VKM9fR44sOX3gb03SpAHdXsNTZDhwUDU9pwP9N8f1ajsQeLwS/px7B1QF4A8BA7 7QbB88XQ8p3Lq7RJTsjvFDi/AKIjhb4YuK42COfjzNYDmg+bsZTDhNAR53fxpbK75/ rlwrs6CaTV50Pcgkfe7J0ayvwnpUbcYT1EzleXpY= From: "Paul E. Jones" To: "Black, David" , "Ben Campbell" , "Michael Welzl" , "Colin Perkins" Date: Thu, 28 Aug 2014 03:13:53 +0000 Message-Id: In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BB4310B@MX15A.corp.emc.com> User-Agent: eM_Client/6.0.20617.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dart/yzsLkt-s-bGMisda0Higmf9oZVk Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [Dart] Treatment of RTCP - proposed text X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 03:13:41 -0000 David, Should it be the DSCP value of the SSRC being reported on or the DSCP of= =20 the SSRC sender? My thought that was if Alice and Bob are sending flows= =20 to each other and Bob is sending audio using EF, then when Bob sends out= =20 a Sender Report, the packet would be marked EF. The way this is worded,= =20 if Alice is sending packets using CS0, then Bob would mark his SR's=20 using CS0. I'm not sure how to handle the RR's, though, particularly of a=20 receive-only device. We could say it would be the same as the flow=20 being reported on, but there might be 31 such flows being reported on. =20 Perhaps if there is agreement that the RTCP packets will be marked in=20 the same way as the sender would send its media, then we say the reports= =20 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=20 transmitted or the same as the received media flow? Paul ------ Original Message ------ From: "Black, David" To: "Paul E. Jones" ; "Ben Campbell"=20 ; "Michael Welzl" ; "Colin Perkins"= =20 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org"=20 ; "dart@ietf.org"=20 ; "avt@ietf.org WG" ; "Black, David"=20 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=20 >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=20 >stream > that is being reported on when that DSCP is known by the RTCP=20 >sender. > When an RTP stream uses multiple DSCPs that differ only in drop > precedence, RTCP reports on that RTP stream should use the DSCP=20 >with > the least likelihood of drop to favor delivery of the RTCP=20 >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=20 >send >the RTP stream, due to en-route remarking. > >If that text looks close, I'll edit further and try to get the -05=20 >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;=20 >>avt@ietf.org >> WG >> Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin=20 >>Perkins >> comments - WGLC: draft-ietf-dart-dscp-rtp-02) >> >> RTCP might not be used for RTT calculations (it might; I just doubt=20 >>it's >> terribly useful), but RTCP might be used to convey QoE measurements=20 >>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= =20 >>for >> the corresponding RTP packets of that sender. In the case where an=20 >>AFxx >> class is used, I'm not sure there is agreement (though no=20 >>disagreement). >> I stated my view that we should use the lowest drop precedence in=20 >>that >> case, but others should weigh in. >> >> Paul >> >> ------ Original Message ------ >> From: "Ben Campbell" >> To: "Michael Welzl" ; "Colin Perkins" >> ; "Paul E. Jones" ; "Black, >> David" >> Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" >> ; "dart@ietf.org" >> ; "avt@ietf.org WG" >> Sent: 8/27/2014 4:48:37 PM >> Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin=20 >>Perkins >> comments - WGLC: draft-ietf-dart-dscp-rtp-02) >> >> >On Aug 27, 2014, at 3:45 PM, Michael Welzl =20 >>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:=20 >>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=20 >>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 > From nobody Wed Aug 27 20:20:56 2014 Return-Path: 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 60C631A0307; Wed, 27 Aug 2014 20:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 ZSOnnmZ2suxk; Wed, 27 Aug 2014 20:20:51 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009231A030B; Wed, 27 Aug 2014 20:20:50 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s7S3Kijg003277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 23:20:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1409196044; bh=c545PER2LlmyNwPZamqivmOmFXeq5F51xWjDCn6YMNc=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type:Content-Transfer-Encoding; b=l6Rn9v/Ux1K57vqV6ogQYJYnV/2Su4DWRG5Iboaf6Eu9DvSGDb0x1196DYYrENCZX CCruRtItsUF5MhQQPwylHqgMDwhibjhmFn3xYmsV/Cr4NpiYN6xTQKEhOvkH0L9wHL NFWvDD2dSqhpIQGMWdFuDRvxpZj0SHU3geb5arhs= From: "Paul E. Jones" To: "Ben Campbell" , "Black, David" Date: Thu, 28 Aug 2014 03:21:13 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.20617.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dart/s4M7eVhu3E5J_e5aAvc8fGmDbSw Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , Colin Perkins , Michael Welzl , "avt@ietf.org WG" Subject: Re: [Dart] Treatment of RTCP - proposed text X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 03:20:52 -0000 Ben, I think the answer is really whether we can quickly reach consensus. I=20 have an idea how I'd implement it if I didn't have guidance otherwise,=20 which I explained in my last email. I think this can be resolved pretty quickly. If not, we can certainly=20 leave it open. Paul ------ Original Message ------ From: "Ben Campbell" To: "Black, David" Cc: "Paul E. Jones" ; "Michael Welzl"=20 ; "Colin Perkins" ;=20 "draft-ietf-dart-dscp-rtp.all@tools.ietf.org"=20 ; "dart@ietf.org"=20 ; "avt@ietf.org WG" Sent: 8/27/2014 10:28:07 PM Subject: Re: Treatment of RTCP - proposed text >I do not object to the text per se. > >But I do have a bit of a nagging concern that we may be offering too=20 >strong of guidance, given the thought process so far. Do we believe we=20 >understand this well enough to say the sender should to this or that,=20 >as opposed to say that these are things the implementer should think=20 >about, and that these are probably reasonable choices? > >Is this an area where we need more deployment experience to offer real=20 >guidance? (I think it's okay for the doc to say that, if needed.) > >But in any case, I will defer to Colin, Paul, and David. > >On Aug 27, 2014, at 8:58 PM, Black, David wrote: > >> 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=20 >>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=20 >>stream >> that is being reported on when that DSCP is known by the RTCP=20 >>sender. >> When an RTP stream uses multiple DSCPs that differ only in drop >> precedence, RTCP reports on that RTP stream should use the DSCP= =20 >>with >> the least likelihood of drop to favor delivery of the RTCP=20 >>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=20 >>send >> the RTP stream, due to en-route remarking. >> >> If that text looks close, I'll edit further and try to get the -05=20 >>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;=20 >>>avt@ietf.org >>> WG >>> Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin=20 >>>Perkins >>> comments - WGLC: draft-ietf-dart-dscp-rtp-02) >>> >>> RTCP might not be used for RTT calculations (it might; I just doubt= =20 >>>it's >>> terribly useful), but RTCP might be used to convey QoE measurements= =20 >>>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= =20 >>>for >>> the corresponding RTP packets of that sender. In the case where an=20 >>>AFxx >>> class is used, I'm not sure there is agreement (though no=20 >>>disagreement). >>> I stated my view that we should use the lowest drop precedence in=20 >>>that >>> case, but others should weigh in. >>> >>> Paul >>> >>> ------ Original Message ------ >>> From: "Ben Campbell" >>> To: "Michael Welzl" ; "Colin Perkins" >>> ; "Paul E. Jones" ;=20 >>>"Black, >>> David" >>> Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" >>> ; "dart@ietf.org" >>> ; "avt@ietf.org WG" >>> Sent: 8/27/2014 4:48:37 PM >>> Subject: Re: [Dart] [AVTCORE] Treatment of RTCP (was Re: Colin=20 >>>Perkins >>> comments - WGLC: draft-ietf-dart-dscp-rtp-02) >>> >>>> On Aug 27, 2014, at 3:45 PM, Michael Welzl =20 >>>>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:=20 >>>>>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= =20 >>>>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 >> > From nobody Wed Aug 27 21:48:15 2014 Return-Path: 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 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" To: "Paul E. Jones" , Ben Campbell , Michael Welzl , Colin Perkins 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> In-Reply-To: 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/dart/Z5gBKihcWEdsbNdiyrKP74T3pXw Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [Dart] Treatment of RTCP - proposed text X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 04:48:09 -0000 PiBTaG91bGQgaXQgYmUgdGhlIERTQ1AgdmFsdWUgb2YgdGhlIFNTUkMgYmVpbmcgcmVwb3J0ZWQg b24gb3IgdGhlIERTQ1Agb2YNCj4gdGhlIFNTUkMgc2VuZGVyPyAgDQoNCkl0IHNob3VsZCBiZSB0 aGUgU1NSQy9SVFAgc3RyZWFtIERTQ1AuICBJIHRoaW5rIHRoZSBwcm9wb3NlZCB0ZXh0IGNvdmVy cw0KdGhhdCBmb3IgYm90aCB0aGUgU1IgYW5kIFJSIGNhc2VzIChCb2Igd291bGQgdXNlIEVGIGlu IHlvdXIgZXhhbXBsZSksIGJ1dA0KSSBhZG1pdCB0byB0aGlua2luZyBtb3JlIGFib3V0IFJScyB3 aGVuIEkgd3JvdGUgdGhlIHByb3Bvc2VkIHRleHQuDQoNCklmIHRoZXJlIGFyZSAzMSBmbG93cyBi ZWluZyByZXBvcnRlZCBvbiBpbiBhIHNpbmdsZSBSVENQIFJSLCBJIHRoaW5rDQp0aGUgcmVjZWl2 ZXIganVzdCBwaWNrcyBhIERTQ1AsIGFzIGl0IG1heSBub3Qga25vdyB0aGUgRFNDUHMgZm9yIGFu eQ0Kb2YgdGhlIGZsb3dzIChlLmcuLCBpZiB0aGV5J3ZlIGFsbCBiZWVuIHJlbWFya2VkIGVucm91 dGUpLiAgSSBkbyBsaWtlDQp0aGUgaWRlYSBvZiBoYXZpbmcgdGhlIHJlcG9ydGVyIHVzZSB0aGUg RFNDUCB0aGF0IGl0IHdvdWxkIHVzZSB0byBzZW5kDQphIHNpbWlsYXIgUlRQIHN0cmVhbSAtIEkn ZCBiZSBoYXBweSB0byBzbGltIHRoZSB0ZXh0IGRvd24gdG8gb25seSANCnJlY29tbWVuZCB0aGF0 LCBhcyBpdCdzIHNpbXBsZXIgYW5kIHRoZSBSVENQIHNlbmRlciBzaG91bGQgYWx3YXlzIGtub3cN CndoYXQgRFNDUCBpdCB3b3VsZCB1c2UgaWYgaXQgd2VyZSBzZW5kaW5nIHNpbWlsYXIgbWVkaWEu DQoNClRoYW5rcywNCi0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBQYXVsIEUuIEpvbmVzIFttYWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29tXQ0KPiBTZW50 OiBXZWRuZXNkYXksIEF1Z3VzdCAyNywgMjAxNCAxMToxNCBQTQ0KPiBUbzogQmxhY2ssIERhdmlk OyBCZW4gQ2FtcGJlbGw7IE1pY2hhZWwgV2Vsemw7IENvbGluIFBlcmtpbnMNCj4gQ2M6IGRyYWZ0 LWlldGYtZGFydC1kc2NwLXJ0cC5hbGxAdG9vbHMuaWV0Zi5vcmc7IGRhcnRAaWV0Zi5vcmc7IGF2 dEBpZXRmLm9yZw0KPiBXRzsgQmxhY2ssIERhdmlkDQo+IFN1YmplY3Q6IFJlOiBUcmVhdG1lbnQg b2YgUlRDUCAtIHByb3Bvc2VkIHRleHQNCj4gDQo+IERhdmlkLA0KPiANCj4gU2hvdWxkIGl0IGJl IHRoZSBEU0NQIHZhbHVlIG9mIHRoZSBTU1JDIGJlaW5nIHJlcG9ydGVkIG9uIG9yIHRoZSBEU0NQ IG9mDQo+IHRoZSBTU1JDIHNlbmRlcj8gIE15IHRob3VnaHQgdGhhdCB3YXMgaWYgQWxpY2UgYW5k IEJvYiBhcmUgc2VuZGluZyBmbG93cw0KPiB0byBlYWNoIG90aGVyIGFuZCBCb2IgaXMgc2VuZGlu ZyBhdWRpbyB1c2luZyBFRiwgdGhlbiB3aGVuIEJvYiBzZW5kcyBvdXQNCj4gYSBTZW5kZXIgUmVw b3J0LCB0aGUgcGFja2V0IHdvdWxkIGJlIG1hcmtlZCBFRi4gIFRoZSB3YXkgdGhpcyBpcyB3b3Jk ZWQsDQo+IGlmIEFsaWNlIGlzIHNlbmRpbmcgcGFja2V0cyB1c2luZyBDUzAsIHRoZW4gQm9iIHdv dWxkIG1hcmsgaGlzIFNSJ3MNCj4gdXNpbmcgQ1MwLg0KPiANCj4gSSdtIG5vdCBzdXJlIGhvdyB0 byBoYW5kbGUgdGhlIFJSJ3MsIHRob3VnaCwgcGFydGljdWxhcmx5IG9mIGENCj4gcmVjZWl2ZS1v bmx5IGRldmljZS4gIFdlIGNvdWxkIHNheSBpdCB3b3VsZCBiZSB0aGUgc2FtZSBhcyB0aGUgZmxv dw0KPiBiZWluZyByZXBvcnRlZCBvbiwgYnV0IHRoZXJlIG1pZ2h0IGJlIDMxIHN1Y2ggZmxvd3Mg YmVpbmcgcmVwb3J0ZWQgb24uDQo+IFBlcmhhcHMgaWYgdGhlcmUgaXMgYWdyZWVtZW50IHRoYXQg dGhlIFJUQ1AgcGFja2V0cyB3aWxsIGJlIG1hcmtlZCBpbg0KPiB0aGUgc2FtZSB3YXkgYXMgdGhl IHNlbmRlciB3b3VsZCBzZW5kIGl0cyBtZWRpYSwgdGhlbiB3ZSBzYXkgdGhlIHJlcG9ydHMNCj4g c2hvdWxkIGJlIG1hcmtlZCBpbiB0aGUgc2FtZSB3YXMgYXMgaXQgd291bGQgaWYgaXQgZGlkIHNl bmQgbWVkaWEuDQo+IA0KPiBTbywgZG8gd2Ugd2FudCBSVENQIHBhY2tldHMgdG8gYmUgbWFya2Vk IHRoZSBzYW1lIGFzIHRoZSBtZWRpYSBmbG93DQo+IHRyYW5zbWl0dGVkIG9yIHRoZSBzYW1lIGFz IHRoZSByZWNlaXZlZCBtZWRpYSBmbG93Pw0KPiANCj4gUGF1bA0KPiANCj4gLS0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0tDQo+IEZyb206ICJCbGFjaywgRGF2aWQiIDxkYXZpZC5ibGFja0Bl bWMuY29tPg0KPiBUbzogIlBhdWwgRS4gSm9uZXMiIDxwYXVsZWpAcGFja2V0aXplci5jb20+OyAi QmVuIENhbXBiZWxsIg0KPiA8YmVuQG5vc3RydW0uY29tPjsgIk1pY2hhZWwgV2VsemwiIDxtaWNo YXdlQGlmaS51aW8ubm8+OyAiQ29saW4gUGVya2lucyINCj4gPGNzcEBjc3BlcmtpbnMub3JnPg0K PiBDYzogImRyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cC5hbGxAdG9vbHMuaWV0Zi5vcmciDQo+IDxk cmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAuYWxsQHRvb2xzLmlldGYub3JnPjsgImRhcnRAaWV0Zi5v cmciDQo+IDxkYXJ0QGlldGYub3JnPjsgImF2dEBpZXRmLm9yZyBXRyIgPGF2dEBpZXRmLm9yZz47 ICJCbGFjaywgRGF2aWQiDQo+IDxkYXZpZC5ibGFja0BlbWMuY29tPg0KPiBTZW50OiA4LzI3LzIw MTQgOTo1ODozNCBQTQ0KPiBTdWJqZWN0OiBUcmVhdG1lbnQgb2YgUlRDUCAtIHByb3Bvc2VkIHRl eHQNCj4gDQo+ID5UcnlpbmcgdG8gcHJvcG9zZSBzb21lIHRleHQgaGVyZToNCj4gPg0KPiA+T0xE DQo+ID4gICAgbyBTaG91bGQgdXNlIGEgc2luZ2xlIERTQ1AgZm9yIGFuIFJUQ1Agc2Vzc2lvbiwg cHJpbWFyaWx5IHRvIGF2b2lkDQo+ID4gICAgICAgUlRDUCByZW9yZGVyaW5nIChhbmQgYmVjYXVz ZSB0aGVyZSBpcyBubyBjb21wZWxsaW5nIHJlYXNvbiBmb3IgdXNlDQo+ID4gICAgICAgb2YgZGlm ZmVyZW50IGRyb3AgcHJlY2VkZW5jZXMpLiBPbmUgb2YgdGhlIFBIQnMgYW5kIGFzc29jaWF0ZWQN Cj4gPiAgICAgICBEU0NQIHVzZWQgZm9yIHRoZSBhc3NvY2lhdGVkIFJUUCB0cmFmZmljIHdvdWxk IGJlIGFuIGFwcHJvcHJpYXRlDQo+ID4gICAgICAgY2hvaWNlLiBbRWRpdG9yJ3Mgbm90ZTogVGhp cyBidWxsZXQgaXMgYW4gb3BlbiB0ZWNobmljYWwgaXNzdWUuXQ0KPiA+TkVXDQo+ID4gICAgbyBT aG91bGQgdXNlIHRoZSBzYW1lIERTQ1AgZm9yIFJUQ1AgcmVwb3J0cyBhcyB1c2VkIGZvciB0aGUg UlRQIHN0cmVhbQ0KPiA+ICAgICAgIHRoYXQgaXMgYmVpbmcgcmVwb3J0ZWQgb24gd2hlbiB0aGF0 IERTQ1AgaXMga25vd24gYnkgdGhlIFJUQ1Agc2VuZGVyLg0KPiA+ICAgICAgIFdoZW4gYW4gUlRQ IHN0cmVhbSB1c2VzIG11bHRpcGxlIERTQ1BzIHRoYXQgZGlmZmVyIG9ubHkgaW4gZHJvcA0KPiA+ ICAgICAgIHByZWNlZGVuY2UsIFJUQ1AgcmVwb3J0cyBvbiB0aGF0IFJUUCBzdHJlYW0gc2hvdWxk IHVzZSB0aGUgRFNDUCB3aXRoDQo+ID4gICAgICAgdGhlIGxlYXN0IGxpa2VsaWhvb2Qgb2YgZHJv cCB0byBmYXZvciBkZWxpdmVyeSBvZiB0aGUgUlRDUCByZXBvcnRzLg0KPiA+ICAgICAgIFdoZW4g YSBzaW5nbGUgUlRDUCBtZXNzYWdlIHJlcG9ydHMgb24gbXVsdGlwbGUgUlRQIHN0cmVhbXMgdGhh dA0KPiA+ICAgICAgIGFyZSBzZW50IHdpdGggZGlmZmVyZW50IERTQ1BzLCB0aGUgUlRDUCBzZW5k ZXIgc2hvdWxkIGNob29zZSBvbmUNCj4gPiAgICAgICBvZiB0aG9zZSBEU0NQcy4gV2hlbiB0aGUg UlRDUCBzZW5kZXIgZG9lcyBub3Qga25vdyB3aGF0IERTQ1Agb3INCj4gPiAgICAgICBEU0NQcyB3 ZXJlIHVzZWQgdG8gc2VuZCBhbiBSVFAgc3RyZWFtLCBpdCBzaG91bGQgY2hvb3NlIGEgRFNDUA0K PiA+ICAgICAgIHRoYXQgaXQgd291bGQgdXNlIHRvIHNlbmQgYSBzaW1pbGFyIFJUUCBzdHJlYW0u DQo+ID4NCj4gPlRoZSBsYXR0ZXIgc2VudGVuY2UgaXMgY291cnRlc3kgb2YgdGhlIGZhY3QgdGhh dCB0aGVyZSB3aWxsIGJlIGNhc2VzDQo+ID53aGVyZSB0aGUgUlRDUCBzZW5kZXIgd2lsbCBub3Qg a25vdyB3aGF0IERTQ1Agb3IgRFNDUHMgd2VyZSB1c2VkIHRvDQo+ID5zZW5kIHRoZSBSVFAgc3Ry ZWFtLCBkdWUgdG8gZW4tcm91dGUgcmVtYXJraW5nLg0KPiA+DQo+ID5JZiB0aGF0IHRleHQgbG9v a3MgY2xvc2UsIEknbGwgZWRpdCBmdXJ0aGVyIGFuZCB0cnkgdG8gZ2V0IHRoZSAtMDUNCj4gPnN1 Ym1pdHRlZCBieSB0aGUgZW5kIG9mIHRoaXMgd2Vlay4NCj4gPg0KPiA+VGhhbmtzLA0KPiA+LS1E YXZpZA0KPiA+DQo+ID4+ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiAgRnJvbTog UGF1bCBFLiBKb25lcyBbbWFpbHRvOnBhdWxlakBwYWNrZXRpemVyLmNvbV0NCj4gPj4gIFNlbnQ6 IFdlZG5lc2RheSwgQXVndXN0IDI3LCAyMDE0IDY6NTMgUE0NCj4gPj4gIFRvOiBCZW4gQ2FtcGJl bGw7IE1pY2hhZWwgV2Vsemw7IENvbGluIFBlcmtpbnM7IEJsYWNrLCBEYXZpZA0KPiA+PiAgQ2M6 IGRyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cC5hbGxAdG9vbHMuaWV0Zi5vcmc7IGRhcnRAaWV0Zi5v cmc7DQo+ID4+YXZ0QGlldGYub3JnDQo+ID4+ICBXRw0KPiA+PiAgU3ViamVjdDogUmU6IFtEYXJ0 XSBbQVZUQ09SRV0gVHJlYXRtZW50IG9mIFJUQ1AgKHdhcyBSZTogQ29saW4NCj4gPj5QZXJraW5z DQo+ID4+ICBjb21tZW50cyAtIFdHTEM6IGRyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cC0wMikNCj4g Pj4NCj4gPj4gIFJUQ1AgbWlnaHQgbm90IGJlIHVzZWQgZm9yIFJUVCBjYWxjdWxhdGlvbnMgKGl0 IG1pZ2h0OyBJIGp1c3QgZG91YnQNCj4gPj5pdCdzDQo+ID4+ICB0ZXJyaWJseSB1c2VmdWwpLCBi dXQgUlRDUCBtaWdodCBiZSB1c2VkIHRvIGNvbnZleSBRb0UgbWVhc3VyZW1lbnRzDQo+ID4+b3IN Cj4gPj4gIG9uZS13YXkgZGVsYXkgaW5mb3JtYXRpb24gdXNlZnVsIGZvciBSTUNBVC4NCj4gPj4N Cj4gPj4gIEkgdGhpbmsgdGhlcmUgaXMgYWdyZWVtZW50IHRoYXQgdGhlIERTQ1AgdmFsdWUgYXBw bGllZCB0byB0aGUgUlRDUA0KPiA+PiAgcGFja2V0IGZvciBhIGdpdmVuIFNTUkMgc2VuZGVyIHNo b3VsZCBhbGlnbiB3aXRoIHRoZSBEU0NQIHZhbHVlIHVzZWQNCj4gPj5mb3INCj4gPj4gIHRoZSBj b3JyZXNwb25kaW5nIFJUUCBwYWNrZXRzIG9mIHRoYXQgc2VuZGVyLiBJbiB0aGUgY2FzZSB3aGVy ZSBhbg0KPiA+PkFGeHgNCj4gPj4gIGNsYXNzIGlzIHVzZWQsIEknbSBub3Qgc3VyZSB0aGVyZSBp cyBhZ3JlZW1lbnQgKHRob3VnaCBubw0KPiA+PmRpc2FncmVlbWVudCkuDQo+ID4+ICAgIEkgc3Rh dGVkIG15IHZpZXcgdGhhdCB3ZSBzaG91bGQgdXNlIHRoZSBsb3dlc3QgZHJvcCBwcmVjZWRlbmNl IGluDQo+ID4+dGhhdA0KPiA+PiAgY2FzZSwgYnV0IG90aGVycyBzaG91bGQgd2VpZ2ggaW4uDQo+ ID4+DQo+ID4+ICBQYXVsDQo+ID4+DQo+ID4+ICAtLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LS0NCj4gPj4gIEZyb206ICJCZW4gQ2FtcGJlbGwiIDxiZW5Abm9zdHJ1bS5jb20+DQo+ID4+ICBU bzogIk1pY2hhZWwgV2VsemwiIDxtaWNoYXdlQGlmaS51aW8ubm8+OyAiQ29saW4gUGVya2lucyIN Cj4gPj4gIDxjc3BAY3NwZXJraW5zLm9yZz47ICJQYXVsIEUuIEpvbmVzIiA8cGF1bGVqQHBhY2tl dGl6ZXIuY29tPjsgIkJsYWNrLA0KPiA+PiAgRGF2aWQiIDxkYXZpZC5ibGFja0BlbWMuY29tPg0K PiA+PiAgQ2M6ICJkcmFmdC1pZXRmLWRhcnQtZHNjcC1ydHAuYWxsQHRvb2xzLmlldGYub3JnIg0K PiA+PiAgPGRyYWZ0LWlldGYtZGFydC1kc2NwLXJ0cC5hbGxAdG9vbHMuaWV0Zi5vcmc+OyAiZGFy dEBpZXRmLm9yZyINCj4gPj4gIDxkYXJ0QGlldGYub3JnPjsgImF2dEBpZXRmLm9yZyBXRyIgPGF2 dEBpZXRmLm9yZz4NCj4gPj4gIFNlbnQ6IDgvMjcvMjAxNCA0OjQ4OjM3IFBNDQo+ID4+ICBTdWJq ZWN0OiBSZTogW0RhcnRdIFtBVlRDT1JFXSBUcmVhdG1lbnQgb2YgUlRDUCAod2FzIFJlOiBDb2xp bg0KPiA+PlBlcmtpbnMNCj4gPj4gIGNvbW1lbnRzIC0gV0dMQzogZHJhZnQtaWV0Zi1kYXJ0LWRz Y3AtcnRwLTAyKQ0KPiA+Pg0KPiA+PiAgPk9uIEF1ZyAyNywgMjAxNCwgYXQgMzo0NSBQTSwgTWlj aGFlbCBXZWx6bCA8bWljaGF3ZUBpZmkudWlvLm5vPg0KPiA+Pndyb3RlOg0KPiA+PiAgPg0KPiA+ PiAgPj4gSSBkb24ndCBrbm93IHRoZSBiZWdpbm5pbmcgb2YgdGhpcyBidXQgSSBjYW4gaGVscCBn byB1cCB0aGUgc3RhY2s6DQo+ID4+ICA+Pg0KPiA+PiAgPj4gZm9yIHRoZSBzaG9ydCBkaWFsb2d1 ZSBiZXR3ZWVuIENvbGluIGFuZCBtZSwgdGhlIGNvbmNsdXNpb24gaXM6DQo+ID4+Q29saW4NCj4g Pj4gID4+aXMgcmlnaHQuIFJUQ1AgcHJvYmFibHkgd29uJ3QgYmUgdXNlZCBieSBjb25nZXN0aW9u IGNvbnRyb2wgdG8NCj4gPj4gID4+ZXN0aW1hdGUgdGhlIFJUVC4NCj4gPj4gID4+DQo+ID4+ICA+ DQo+ID4+ICA+VGhhbmtzLCBNaWNoYWVsLCBJIHRoaW5rIHRoYXQgZml0cyB3aXRoIHNvbWUgZWFy bGllciBjb252ZXJzYXRpb25zDQo+ID4+YXMNCj4gPj4gID53ZWxsLg0KPiA+PiAgPg0KPiA+PiAg PkNvbGluIGFuZCBQYXVsIChhbmQgRGF2aWQpOg0KPiA+PiAgPg0KPiA+PiAgPkFyZSB3ZSBjb252 ZXJnaW5nIG9uIHdoYXQgZ3VpZGFuY2UgdG8gcHV0IGludG8gdGhlIERBUlQgZHJhZnQ/DQo+ID4+ ICA+DQo+ID4+ICA+VGhhbmtzIQ0KPiA+PiAgPg0KPiA+PiAgPkJlbi4NCj4gPj4gID4NCj4gPj4g ID4NCj4gPj4gID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+PiAgPkRhcnQgbWFpbGluZyBsaXN0DQo+ID4+ICA+RGFydEBpZXRmLm9yZw0KPiA+PiAg Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGFydA0KPiA+DQoNCg== From nobody Thu Aug 28 01:56:26 2014 Return-Path: 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 0B7451A0B80; Thu, 28 Aug 2014 01:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 RUzDhZSvN6A7; Thu, 28 Aug 2014 01:56:20 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AF71A0B73; Thu, 28 Aug 2014 01:56:20 -0700 (PDT) Received: from [130.209.247.112] (port=57845 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XMvV5-0005ut-Ft; Thu, 28 Aug 2014 09:56:13 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Thu, 28 Aug 2014 09:55:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <439DC2BA-155E-4880-A665-0DFCEB48BFAC@csperkins.org> References: To: "Paul E. Jones" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/DiXYO4_Ye5CqtN-lZqbslIlOwsc Cc: Ben Campbell , Michael Welzl , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [Dart] Treatment of RTCP - proposed text X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 08:56:23 -0000 Paul, David, On 28 Aug 2014, at 04:13, Paul E. Jones wrote: > 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. =20 Agree. An SSRC should use the same marking it would use to send packets, = and not the marking of the received packets. > The way this is worded, if Alice is sending packets using CS0, then = Bob would mark his SR's using CS0. >=20 > 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. A receive-only device should mark in the way it would if it sent media, = I agree. > So, do we want RTCP packets to be marked the same as the media flow = transmitted or the same as the received media flow? Transmitted, I think. Colin > Paul >=20 > ------ Original Message ------ > From: "Black, David" > To: "Paul E. Jones" ; "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" = > Sent: 8/27/2014 9:58:34 PM > Subject: Treatment of RTCP - proposed text >=20 >> Trying to propose some text here: >>=20 >> 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. >>=20 >> 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. >>=20 >> If that text looks close, I'll edit further and try to get the -05 = submitted >> by the end of this week. >>=20 >> Thanks, >> --David >>=20 >>> -----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) >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Paul >>>=20 >>> ------ Original Message ------ >>> From: "Ben Campbell" >>> To: "Michael Welzl" ; "Colin Perkins" >>> ; "Paul E. Jones" ; = "Black, >>> David" >>> Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" >>> ; "dart@ietf.org" >>> ; "avt@ietf.org WG" >>> 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) >>>=20 >>> >On Aug 27, 2014, at 3:45 PM, Michael Welzl = 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 >>=20 >=20 --=20 Colin Perkins http://csperkins.org/ From nobody Thu Aug 28 04:02:29 2014 Return-Path: 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 9166C1A6F76; Thu, 28 Aug 2014 04:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 LKX9OnQb5TGP; Thu, 28 Aug 2014 04:02:13 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57A31A6F75; Thu, 28 Aug 2014 04:02:13 -0700 (PDT) Received: from [130.209.247.112] (port=58590 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XMxSx-0004fY-AZ; Thu, 28 Aug 2014 12:02:08 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BB42E15@MX15A.corp.emc.com> Date: Thu, 28 Aug 2014 12:02:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712077BB42E15@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/H8LAlt7bloICI8NbJ56U7VXhQqI Cc: Ben Campbell , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , "avt@ietf.org WG" , "Paul E. Jones" Subject: Re: [Dart] draft-ietf-dart-dscp-rtp-02 - Section 5.3 RTCP multi-stream optimization text X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 11:02:18 -0000 David, On 26 Aug 2014, at 17:27, Black, David wrote: > >=20 > Colin writes: >=20 > The discussion of the multi-stream-optimisation draft is a separate > issue, and is correct as it is. >=20 > Looking closer, that discussion in the current DART draft currently = says: >=20 > 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. A quick follow-up to ensure this is clear: the multi-stream-optimisation = cannot be used when reporting on received RTP streams where the = different streams have different markings, since those streams are = treated differently in the network.=20 The marking I use for the RTP streams I send (and hence the marking I = use for my RTCP packets) doesn=92t influence whether I can use the = multi-stream-optimisation, however. Colin > That's based on this text from the last paragraph of Section 1 > (Introduction) of the multi-stream optimization draft: >=20 > This memo defines such an RTCP extension, RTCP Reporting Groups. > This extension is used to indicate the SSRCs that originate from the > same endpoint, and therefore have identical reception quality, hence > allowing the endpoints to suppress unnecessary RTCP reception = quality > reports. >=20 > When different DSCPs are used for SSRCs (RTP streams) that originate > from the same source, the statement that they "therefore have = identical > reception quality" is clearly incorrect, so it looks like the current > DART draft text is correct, IMHO. >=20 > Harald? >=20 > >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Tuesday, August 26, 2014 11:54 AM >> To: Black, David >> Cc: Ben Campbell; Paul E. Jones; dart@ietf.org; avt@ietf.org WG; = draft-ietf- >> dart-dscp-rtp.all@tools.ietf.org >> Subject: Re: Treatment of RTCP (was Re: [Dart] Colin Perkins comments = - WGLC: >> draft-ietf-dart-dscp-rtp-02) >>=20 >>=20 >> On 26 Aug 2014, at 16:39, Black, David wrote: >>=20 >>>>> 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. >>>>=20 >>>> That makes sense to me. Paul, and others, do you agree with that = last >>>> paragraph? >>>=20 >>> >>>=20 >>> 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. >>>=20 >>> >>>=20 >>> 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!). >>=20 >> 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. >>=20 >>> That statement seems valuable to make and can be made with a = citation of >>> RFC 3530, as opposed to the multi-stream optimization draft. >>>=20 >>> Harald and Colin - what do you think? >>=20 >> The discussion of the multi-stream-optimisation draft is a separate = issue, and >> is correct as it is. >>=20 >> -- >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >=20 --=20 Colin Perkins http://csperkins.org/ From nobody Thu Aug 28 04:05:56 2014 Return-Path: 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 AA9791A0503; Thu, 28 Aug 2014 04:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6] autolearn=no 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 ia_NNxlm2LTg; Thu, 28 Aug 2014 04:05:52 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB631A0515; Thu, 28 Aug 2014 04:05:52 -0700 (PDT) Received: from [130.209.247.112] (port=58615 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XMxWS-00056W-C1; Thu, 28 Aug 2014 12:05:47 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Thu, 28 Aug 2014 12:05:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Paul E. Jones" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/ey-jNqh8yhESkymadGcpo301iSg Cc: Ben Campbell , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 11:05:54 -0000 Paul, On 27 Aug 2014, at 22:41, Paul E. Jones 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? >>>>=20 >>>> 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. >>>=20 >>> I'm a little confused here. These are separate SSRCs, but all part = of a single RTP session. So, wouldn=92t the three SSRCs be reported in = different report blocks in the sender report? >>=20 >> Each of the SSRCs will report on all the others, unless the = rtp-multi-stream-optimisation draft is used, but so what? >=20 > 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=92s = 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. >>>> 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? >>>=20 >>> 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. >>=20 >> 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? >=20 > 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. --=20 Colin Perkins http://csperkins.org/ From nobody Thu Aug 28 10:31:18 2014 Return-Path: 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 E07571A87AC; Thu, 28 Aug 2014 10:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=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 iXD5UBkMLUxP; Thu, 28 Aug 2014 10:31:13 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2171A0137; Thu, 28 Aug 2014 10:31:13 -0700 (PDT) Received: from [213.205.233.181] (port=47836 helo=[10.174.172.224]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XN3XR-0007DG-7Q; Thu, 28 Aug 2014 18:31:11 +0100 References: <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> <8D3D17ACE214DC429325B2B98F3AE712077BB42E1F@MX15A.corp.emc.com> <22E25F9C-E9B1-4C3C-989E-570BAAF58018@csperkins.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Colin Perkins Date: Thu, 28 Aug 2014 18:31:01 +0100 To: Michael Welzl X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/pJA6Jlg5aUXHomh3bo3fd3vnYA0 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "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) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 17:31:15 -0000 > On 27 Aug 2014, at 19:39, Michael Welzl wrote: >=20 >=20 >> On 27. aug. 2014, at 18:00, Colin Perkins wrote: >>=20 >> On 26 Aug 2014, at 17:38, Black, David wrote: >>>> The more difficult case is when an SSRC is sending video using differen= t >>>> 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 R= TP >>>> packets carrying P-frames, or what? >>>=20 >>> Answering a question w/a question :-), how are those reports likely to b= e used? >>>=20 >>> 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 indica= tive >>> 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 inc= rease >>> may be reasonable), which suggests P-frame-like RTCP report marking. >>=20 >> I doubt the RTT estimate derived from RTCP is used for congestion control= , since it=E2=80=99s too infrequent to get insight into the dynamics. It=E2=80= =99s for user experience reporting, maybe rough clustering of receivers, tha= t sort of thing. >=20 > 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.=20 Colin= From nobody Thu Aug 28 11:03:18 2014 Return-Path: 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 C5DB81A88DB; Thu, 28 Aug 2014 11:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ZVG0pV9UzG50; Thu, 28 Aug 2014 11:03:06 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B07E1A0B79; Thu, 28 Aug 2014 11:03:06 -0700 (PDT) Received: from [81.187.2.149] (port=34034 helo=[192.168.0.22]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XN42H-0000RR-GW; Thu, 28 Aug 2014 19:03:02 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Thu, 28 Aug 2014 19:02:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9E8BAB84-3666-4692-8CF1-8FFE285DDF1B@csperkins.org> References: <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> <8D3D17ACE214DC429325B2B98F3AE712077BB42E1F@MX15A.corp.emc.com> <22E25F9C-E9B1-4C3C-989E-570BAAF58018@csperkins.org> To: Michael Welzl X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/x16ttyPFVnKArLZi2O6NIrXea_Q Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "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) X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 18:03:10 -0000 On 28 Aug 2014, at 18:31, Colin Perkins wrote: >> On 27 Aug 2014, at 19:39, Michael Welzl wrote: >>=20 >>> On 27. aug. 2014, at 18:00, Colin Perkins wrote: >>>=20 >>> On 26 Aug 2014, at 17:38, Black, David wrote: >>>>> 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? >>>>=20 >>>> Answering a question w/a question :-), how are those reports likely = to be used? >>>>=20 >>>> 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. >>>=20 >>> I doubt the RTT estimate derived from RTCP is used for congestion = control, since it=92s too infrequent to get insight into the dynamics. = It=92s for user experience reporting, maybe rough clustering of = receivers, that sort of thing. >>=20 >> 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? >=20 > Yes, as I replied a couple of days ago.=20 Wait, sorry, that was the email I replied to a couple of days ago = reappearing=85 RTT probing, I guess :-) --=20 Colin Perkins http://csperkins.org/ From nobody Thu Aug 28 11:12:27 2014 Return-Path: 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 3C7221A88E9 for ; Thu, 28 Aug 2014 11:12:25 -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 6g5R5mtVOtDC for ; Thu, 28 Aug 2014 11:12:22 -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 915171A88DE for ; Thu, 28 Aug 2014 11:12:22 -0700 (PDT) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SICH32019718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2014 14:12:18 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s7SICH32019718 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409249538; bh=pFClN5GrLLg4xOL9PtV9wngIIGQ=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=bBARcBj2fQMaGGkQUCp84PNvNzOejLHjgzuqZTDCuTljES2T8hSw8zDl1Ejk0fWpB 2n3PmOVlJpAryitlqj/5DDSDHhm+28iE127UxyzfKoSKlXGaExlgUT9Bl8+GAuWPIx HJSAuXJfEQwrahLPK3GGp3QHPB3MWtmcAqUCefqY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s7SICH32019718 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd54.lss.emc.com (RSA Interceptor); Thu, 28 Aug 2014 14:12:06 -0400 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SIC7nC018488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 14:12:07 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Thu, 28 Aug 2014 14:12:07 -0400 From: "Black, David" To: "dart@ietf.org" Date: Thu, 28 Aug 2014 14:12:05 -0400 Thread-Topic: draft-dart-dscp-rtp - way forward Thread-Index: Ac/C64/SYiRrXJI/SU+LRj1F3IDkaA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" 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/RJLU3rQbhhhuG4SrAlDHRgn_e7o Cc: "Colin Perkins \(csp@csperkins.org\)" Subject: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 18:12:25 -0000 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=20 --> 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 suspec= t 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=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Thu Aug 28 11:23:02 2014 Return-Path: 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 3B4B11A88FD for ; Thu, 28 Aug 2014 11:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 GUfS2azk3dpy for ; Thu, 28 Aug 2014 11:22:58 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696001A88DF for ; Thu, 28 Aug 2014 11:22:58 -0700 (PDT) Received: from [81.187.2.149] (port=34969 helo=[192.168.0.22]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XN4LV-0002tt-Vl; Thu, 28 Aug 2014 19:22:56 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> Date: Thu, 28 Aug 2014 19:22:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <273D5752-EA79-4E89-8B54-B13F338DF841@csperkins.org> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/IaxawYK99WrKZlLzhEgxM60wIlM Cc: "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 18:23:00 -0000 On 28 Aug 2014, at 19:12, Black, David wrote: > 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. >=20 > Reminder - we had 6 WG LC open issues and work items: >=20 > [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. >=20 > --> 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. >=20 > [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 >=20 > --> 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=20= > --> DSCP to use should be the one that would be used to send a similar > --> RTP stream. The distinction between RTCP SR and RR isn=92t 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=92t = send any RTP packets, it marks its RTCP packets with the marking it = would use if it did send RTP. > --> 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 > =97> 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.=20 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 > --> 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. >=20 > [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." >=20 > --> Done, text is in -04, with some minor edits coming in -05. >=20 > [D] Open issue: Question to Harald Alvestrand - Does CNAME need to be = used > in section 2.2 text? I hope not. >=20 > --> Closed via a small text deletion in section 2.1 of -04 draft. >=20 > [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. >=20 > --> 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. >=20 > [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]. >=20 > --> 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. >=20 > 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. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 --=20 Colin Perkins http://csperkins.org/ From nobody Thu Aug 28 12:34:07 2014 Return-Path: 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 9A5B61A8990 for ; Thu, 28 Aug 2014 12:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 2AgWfmbFa9FH for ; Thu, 28 Aug 2014 12:33:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6461A897F for ; Thu, 28 Aug 2014 12:33:59 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7SJXkwE064283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Aug 2014 14:33:48 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <273D5752-EA79-4E89-8B54-B13F338DF841@csperkins.org> Date: Thu, 28 Aug 2014 14:33:45 -0500 X-Mao-Original-Outgoing-Id: 430947225.912883-3cb80b8946388cade585a751e9209e9c Content-Transfer-Encoding: quoted-printable Message-Id: <2C0A71FC-D92E-4D2D-B425-1662A7938386@nostrum.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <273D5752-EA79-4E89-8B54-B13F338DF841@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/dGuERPYke18kB0xc-NCZjmwDUuM Cc: "Black, David" , "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 19:34:05 -0000 On Aug 28, 2014, at 1:22 PM, Colin Perkins wrote: >> [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 >>=20 >> --> 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=20 >> --> DSCP to use should be the one that would be used to send a = similar >> --> RTP stream. >=20 > The distinction between RTCP SR and RR isn=92t 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=92t = 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 nobody Thu Aug 28 12:41:58 2014 Return-Path: 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 AFEBE1A897F for ; Thu, 28 Aug 2014 12:41:56 -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 OTN4SCaGbSGd for ; Thu, 28 Aug 2014 12:41:55 -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 B7D911A896F for ; Thu, 28 Aug 2014 12:41:54 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SJfloD015646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2014 15:41:48 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7SJfloD015646 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409254909; bh=+xEAchZFxtWwR2AHko4V414xgK4=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=nUOgameunx8fV6ZyXmlREMyolqqQgZniib+bP7BcRha/uuY6t9xkLDW4LiZYPpva6 tDcGZgje33I6JnznUJfLueciuVkX3WdJbK465T2f6U7XrzIq6Tx0TZkSjqtdeXothF BOVrgIaH6IuBsfpw15yt+Hxau01JHiMHxUXeNqx0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7SJfloD015646 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd03.lss.emc.com (RSA Interceptor); Thu, 28 Aug 2014 15:41:31 -0400 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SJfdGq016733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 15:41:39 -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 15:41:39 -0400 From: "Black, David" To: Ben Campbell , Colin Perkins Date: Thu, 28 Aug 2014 15:41:38 -0400 Thread-Topic: [Dart] draft-dart-dscp-rtp - way forward Thread-Index: Ac/C9wYbiNvKaQB2Ra2ObdT3X81/xQAAPXGQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BC66828@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <273D5752-EA79-4E89-8B54-B13F338DF841@csperkins.org> <2C0A71FC-D92E-4D2D-B425-1662A7938386@nostrum.com> In-Reply-To: <2C0A71FC-D92E-4D2D-B425-1662A7938386@nostrum.com> 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: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/SCwTXYLzqp8ryHcbmwLALf1bCuA Cc: "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 19:41:56 -0000 > > 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 di= d > send RTP. >=20 > That last bit concerns me a bit. Are we really asking an implementation t= o > figure out how it would have done something it isn't going to do? Yes, --David > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Thursday, August 28, 2014 3:34 PM > To: Colin Perkins > Cc: Black, David; dart@ietf.org > Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >=20 >=20 > On Aug 28, 2014, at 1:22 PM, Colin Perkins wrote: >=20 > >> [B] Open issue: PHBs and DSCPs for RTCP. The RTCP guideline bullet ca= nnot > >> 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 sho= uld > >> --> 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. > > > > 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 di= d > send RTP. >=20 > That last bit concerns me a bit. Are we really asking an implementation t= o > figure out how it would have done something it isn't going to do? From nobody Thu Aug 28 12:44:28 2014 Return-Path: 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 B426C1A0193 for ; Thu, 28 Aug 2014 12:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 fKwEum87zCK7 for ; Thu, 28 Aug 2014 12:44:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8529B1A897F for ; Thu, 28 Aug 2014 12:44:25 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7SJi2QM065153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Aug 2014 14:44:03 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> Date: Thu, 28 Aug 2014 14:44:01 -0500 X-Mao-Original-Outgoing-Id: 430947841.504436-52e951b8f28ed9358cbd8d7429dc5379 Content-Transfer-Encoding: quoted-printable Message-Id: <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> To: "Black, David" , Harald Tveit Alvestrand X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/PH8M9P3nBd4U5uQO6-XM-yhg4d8 Cc: "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 19:44:26 -0000 (as chair) On Aug 28, 2014, at 1:12 PM, Black, David wrote: > [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. >=20 > --> 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. 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 nobody Thu Aug 28 12:45:38 2014 Return-Path: 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 AA6EE1A89AD; Thu, 28 Aug 2014 12:45:26 -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 keJmawp0R-WU; Thu, 28 Aug 2014 12:45:24 -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 61B781A89A6; Thu, 28 Aug 2014 12:45:24 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SJjG9L008996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2014 15:45:21 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s7SJjG9L008996 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409255121; bh=vZT70phfrOxur8a7vDJnHuFralk=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=FbsYoMc4YzTnHxXi6skK3EfbW7ljW9R2YStflF8IIOLPJDOKnZW6uZCuUq+uA0mR9 VhYYkzaHPx8ClZdjoGIKQblgLksG3XtnXxGlOYwXeHhWedYT1kb8fnLAIEL8Ou5wSl zws+iyuoKsxADxcIW/vQNHHogAymqeB94zvToPso= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s7SJjG9L008996 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd06.lss.emc.com (RSA Interceptor); Thu, 28 Aug 2014 15:44:59 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SJjBRC007956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 15:45:12 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Thu, 28 Aug 2014 15:45:11 -0400 From: "Black, David" To: "dart@ietf.org" , "avt@ietf.org WG (avt@ietf.org)" Date: Thu, 28 Aug 2014 15:45:10 -0400 Thread-Topic: DART dscp-rtp draft: Proposed RTCP text Thread-Index: Ac/C+JCMaR5kxHNdT2yBh8eoXL4k6Q== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BC6682D@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/gfgkljL-fDxMVZasaGQJO4LxyVc Cc: "ben@nostrum.com" , "Black, David" , "Colin Perkins \(csp@csperkins.org\)" Subject: [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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 19:45:28 -0000 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 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. 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. 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. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Thu Aug 28 12:48:34 2014 Return-Path: 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 DF8211A89AD for ; Thu, 28 Aug 2014 12:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 yLLRl--Cys_8 for ; Thu, 28 Aug 2014 12:48:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E691D1A8978 for ; Thu, 28 Aug 2014 12:48:31 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7SJmMRO065556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Aug 2014 14:48:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BC66828@MX15A.corp.emc.com> Date: Thu, 28 Aug 2014 14:48:21 -0500 X-Mao-Original-Outgoing-Id: 430948101.536142-5cd10b853ea1ea2710e17c355d99a083 Content-Transfer-Encoding: quoted-printable Message-Id: <98417316-1D34-4C62-9A29-8F8CC5D9A42A@nostrum.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <273D5752-EA79-4E89-8B54-B13F338DF841@csperkins.org> <2C0A71FC-D92E-4D2D-B425-1662A7938386@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66828@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/4r_HcRXNy_ESlqbWNC0aSMDt4hI Cc: "dart@ietf.org" , Colin Perkins Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 19:48:33 -0000 On Aug 28, 2014, at 2:41 PM, Black, David 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. >>=20 >> 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? >=20 > Yes, --David 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 nobody Thu Aug 28 13:13:10 2014 Return-Path: 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 4F6461A0191 for ; Thu, 28 Aug 2014 13:13:08 -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 BhAR5OOrkI82 for ; Thu, 28 Aug 2014 13:13:06 -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 6FBFA1A0155 for ; Thu, 28 Aug 2014 13:13:06 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SKD1aE024507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2014 16:13:03 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7SKD1aE024507 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409256783; bh=xERdfzZBvegXZBGcOQgVou4a/N8=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=YfJOUDnZS0BPrnBdVNOhCM5L3IEKlDs0P0ou9ez0buOrUq4W9jk/XVrs9Y7r+035n ODz8Lr24+CDWrPgWT+LzcnDZLnR2ppGTMGE+M9BO4kq/7kcW3AfohcWVidAhP6xZhs 2DzgERdf0C0Ylx8JgIuLx4VLeomOWxDiIMGLqmaw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7SKD1aE024507 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 16:12:39 -0400 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SKCqT8001523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 16:12:52 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Thu, 28 Aug 2014 16:12:51 -0400 From: "Black, David" To: Ben Campbell Date: Thu, 28 Aug 2014 16:12:51 -0400 Thread-Topic: [Dart] draft-dart-dscp-rtp - way forward Thread-Index: Ac/C+Q1FMVubg3MmT+ysmudphGv/cwAA1YoA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BC6683F@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <273D5752-EA79-4E89-8B54-B13F338DF841@csperkins.org> <2C0A71FC-D92E-4D2D-B425-1662A7938386@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66828@MX15A.corp.emc.com> <98417316-1D34-4C62-9A29-8F8CC5D9A42A@nostrum.com> In-Reply-To: <98417316-1D34-4C62-9A29-8F8CC5D9A42A@nostrum.com> 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: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/imxqG20BQpQuZ7wDmS6BcKUlQLA Cc: "dart@ietf.org" , Colin Perkins Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:13:08 -0000 > 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 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Thursday, August 28, 2014 3:48 PM > To: Black, David > Cc: Colin Perkins; dart@ietf.org > Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >=20 >=20 > On Aug 28, 2014, at 2:41 PM, Black, David wrote: >=20 > >>> The distinction between RTCP SR and RR isn't useful here. What you wa= nt 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 implementatio= n to > >> figure out how it would have done something it isn't going to do? > > > > Yes, --David >=20 > 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? >=20 > (Right now I am not sending audio, video, or interactive-holodeck-with-sm= ell- > o-vision). From nobody Thu Aug 28 13:17:17 2014 Return-Path: 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 7F5421A89B5 for ; Thu, 28 Aug 2014 13:17:08 -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 RigQFoV8fGjx for ; Thu, 28 Aug 2014 13:17:05 -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 802951A89C7 for ; Thu, 28 Aug 2014 13:16:45 -0700 (PDT) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SKGcg3025541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2014 16:16:40 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7SKGcg3025541 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409257000; bh=mEBbCEGGYrn1QJQ4AxeYPbLER54=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=vv2bT/+TkxIYZzb9+ZbuGUJjw2kg+TJcPe05FN6X7pEi6r9jsFsutXYE/YgH66EQI qtc+8EXOXNi2vuo2/DE3rQh3+/DJbZt5Zi7Cm5JkRn02HJ/qaODpZtgU7gjYoZkw/9 lvPNhGsCGGp/eO5qaAp4KqKJhGQQ9nbVVaOcHp0M= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7SKGcg3025541 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd04.lss.emc.com (RSA Interceptor); Thu, 28 Aug 2014 16:16:13 -0400 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SKDgFV031008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 16:16:21 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Thu, 28 Aug 2014 16:15:38 -0400 From: "Black, David" To: Ben Campbell , Harald Tveit Alvestrand Date: Thu, 28 Aug 2014 16:15:36 -0400 Thread-Topic: [Dart] draft-dart-dscp-rtp - way forward Thread-Index: Ac/C+Hxgwhy1/rSZRsSes7ES854AwQAA/3dQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> In-Reply-To: <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> 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: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/TT_4RyE5ebM27cFULfN34XEVcWI Cc: "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:17:09 -0000 > If we think we can close this as not a real issue (or at least not an iss= ue 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 closu= re, > 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 believe= s to > be as complete is it's going to get. In private discussion, both Harald and I favored saying less (rather than m= ore) 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 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Thursday, August 28, 2014 3:44 PM > To: Black, David; Harald Tveit Alvestrand > Cc: dart@ietf.org > Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >=20 > (as chair) >=20 > On Aug 28, 2014, at 1:12 PM, Black, David wrote: >=20 > > [E] Open issue: Harald Alvestrand's concerns about "differential treatm= ent" > > wrt Section 5.1 . I don't completely understand these concerns, and su= spect > > 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 opportu= nity > > --> to share any further thoughts, so I don't think there's anything to= be > done > > --> about this now. >=20 > I have mixed feelings on this. >=20 > If we think we can close this as not a real issue (or at least not an iss= ue 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 closu= re, > 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 believe= s to > be as complete is it's going to get. >=20 > David, thoughts? >=20 > Harald, do you care to comment further? From nobody Thu Aug 28 13:25:32 2014 Return-Path: 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 AD2AD1A89A7 for ; Thu, 28 Aug 2014 13:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 jZO_u-goXRQo for ; Thu, 28 Aug 2014 13:25:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D641A8987 for ; Thu, 28 Aug 2014 13:25:27 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7SKP6xG073590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Aug 2014 15:25:08 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> Date: Thu, 28 Aug 2014 15:25:05 -0500 X-Mao-Original-Outgoing-Id: 430950305.599164-88e14679d46818fc1f90ffd3cc978fed Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/DXMVq7BJT8tGipaxAix8jyso2NM Cc: Harald Tveit Alvestrand , "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:25:29 -0000 Okay, works for me. Thanks! Ben. On Aug 28, 2014, at 3:15 PM, Black, David wrote: >> 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. >=20 > 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. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Thursday, August 28, 2014 3:44 PM >> To: Black, David; Harald Tveit Alvestrand >> Cc: dart@ietf.org >> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >>=20 >> (as chair) >>=20 >> On Aug 28, 2014, at 1:12 PM, Black, David = wrote: >>=20 >>> [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. >>>=20 >>> --> 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. >>=20 >> I have mixed feelings on this. >>=20 >> 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. >>=20 >> David, thoughts? >>=20 >> Harald, do you care to comment further? From nobody Thu Aug 28 13:27:13 2014 Return-Path: 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 AB4A01A8A4F for ; Thu, 28 Aug 2014 13:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 fYHnBFMxKjD6 for ; Thu, 28 Aug 2014 13:27:09 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9093E1A89A7 for ; Thu, 28 Aug 2014 13:27:09 -0700 (PDT) Received: from [81.187.2.149] (port=45193 helo=[192.168.0.22]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XN6Hi-0001wk-FM; Thu, 28 Aug 2014 21:27:07 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <98417316-1D34-4C62-9A29-8F8CC5D9A42A@nostrum.com> Date: Thu, 28 Aug 2014 21:27:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <72E15CBE-F8B0-41C5-A03A-435D58C2381F@csperkins.org> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <273D5752-EA79-4E89-8B54-B13F338DF841@csperkins.org> <2C0A71FC-D92E-4D2D-B425-1662A7938386@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66828@MX15A.corp.emc.com> <98417316-1D34-4C62-9A29-8F8CC5D9A42A@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/2LnD0JyDd8JICDK4i7en93GkHKw Cc: "Black, David" , "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:27:11 -0000 On 28 Aug 2014, at 20:48, Ben Campbell wrote: > On Aug 28, 2014, at 2:41 PM, Black, David 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=92t = send any RTP packets, it marks its RTCP packets with the marking it = would use if it did send RTP. >>>=20 >>> That last bit concerns me a bit. Are we really asking an = implementation to figure out how it would have done something it isn=92t = going to do? >>=20 >> Yes, --David >=20 > 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? Yes, that=92s how RTP works.=20 --=20 Colin Perkins http://csperkins.org/ From nobody Thu Aug 28 13:29:32 2014 Return-Path: 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 79C381A89A7 for ; Thu, 28 Aug 2014 13:29:31 -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 rWpJ6_bsBeXB for ; Thu, 28 Aug 2014 13:29:30 -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 DD5971A8987 for ; Thu, 28 Aug 2014 13:29:29 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SKTNf3011659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2014 16:29:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s7SKTNf3011659 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409257765; bh=+WhVkTYgbDxQgOVKHEgGhFuElME=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=SRs6l94by+zbPqsSr1zloxSqZp/8698nOSzxnPUUZcPfQhy7d0SpS62Wsry1gJiT2 Y4pvmgss8SSPAmQvb7RAQYZqua+Lsm+p53hZ5Hx2YXYSjKO41UpQN04BlXfhwko4h7 t+le2oB/J3pXZ38Kwz+lQ+qIwmP9gnOhwvHo0SB8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s7SKTNf3011659 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd55.lss.emc.com (RSA Interceptor); Thu, 28 Aug 2014 16:29:00 -0400 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SKT8jk003074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 16:29:08 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Thu, 28 Aug 2014 16:29:08 -0400 From: "Black, David" To: Colin Perkins , Ben Campbell Date: Thu, 28 Aug 2014 16:29:07 -0400 Thread-Topic: [Dart] draft-dart-dscp-rtp - way forward Thread-Index: Ac/C/nIvhN1S6yX0Ssu5Yaxth/YfAAAADvAw Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BC66848@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <273D5752-EA79-4E89-8B54-B13F338DF841@csperkins.org> <2C0A71FC-D92E-4D2D-B425-1662A7938386@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66828@MX15A.corp.emc.com> <98417316-1D34-4C62-9A29-8F8CC5D9A42A@nostrum.com> <72E15CBE-F8B0-41C5-A03A-435D58C2381F@csperkins.org> In-Reply-To: <72E15CBE-F8B0-41C5-A03A-435D58C2381F@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: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/R5ixVaLoRkzldyu6UPgEy11G5s0 Cc: "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:29:31 -0000 I'll go add a sentence to explain that to the draft 5.4 text ... Thanks, --David > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Thursday, August 28, 2014 4:27 PM > To: Ben Campbell > Cc: Black, David; dart@ietf.org > Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >=20 > On 28 Aug 2014, at 20:48, Ben Campbell wrote: > > On Aug 28, 2014, at 2:41 PM, Black, David wrote: > >>>> The distinction between RTCP SR and RR isn't useful here. What you w= ant > 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 di= d > send RTP. > >>> > >>> That last bit concerns me a bit. Are we really asking an implementati= on to > figure out how it would have done something it isn't going to do? > >> > >> Yes, --David > > > > 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? >=20 > Yes, that's how RTP works. >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 From nobody Thu Aug 28 13:36:59 2014 Return-Path: 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 1CFF11A8A64; Thu, 28 Aug 2014 13:36:56 -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 P-vxDjxzAO7U; Thu, 28 Aug 2014 13:36:54 -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 0B56D1A8A04; Thu, 28 Aug 2014 13:36:53 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SKaiqc031372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2014 16:36:44 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7SKaiqc031372 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409258204; bh=sG30a36n96wTxGEUzKlGqvMrC2A=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=vJXgslo7KNPgi/ZApcVMP3yEyRLhsZFGDqA/ZJVXmEE7LQ6XdgMrFWlHdsZMGee29 NuQ+24E93BkUdpUTkbZ0iNsPZT28JF1p3CAYrl5pYsRKvpscnvX9uuan0CUtwCjKUR QT3GwnhZAuZiAkGWzFfJ8/KwlgcWKGXr5N7XQHoI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7SKaiqc031372 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd05.lss.emc.com (RSA Interceptor); Thu, 28 Aug 2014 16:36:26 -0400 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7SKaQuj006783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 16:36:26 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Thu, 28 Aug 2014 16:36:26 -0400 From: "Black, David" To: "dart@ietf.org" , "avt@ietf.org WG (avt@ietf.org)" Date: Thu, 28 Aug 2014 16:36:25 -0400 Thread-Topic: DART dscp-rtp draft: Proposed RTCP text Thread-Index: Ac/C+JCMaR5kxHNdT2yBh8eoXL4k6QABvR9g Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BC6684C@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BC6682D@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BC6682D@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Y7xA34gqz6ZJCyfFlcRTvOhXpAM Cc: "ben@nostrum.com" , "Colin Perkins \(csp@csperkins.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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:36:56 -0000 Minor edit to proposed text below: OLD 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. NEW 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 with media similar to the RTP traffic that it receives. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Thursday, August 28, 2014 3:45 PM > To: dart@ietf.org; avt@ietf.org WG (avt@ietf.org) > Cc: Black, David; Colin Perkins (csp@csperkins.org); ben@nostrum.com > Subject: DART dscp-rtp draft: Proposed RTCP text >=20 > 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: >=20 > 5.4. DiffServ and RTCP >=20 > 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. >=20 > 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. > 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. >=20 > 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. >=20 > 6. Guidelines >=20 > [... snip ...] >=20 > 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. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 From nobody Thu Aug 28 13:45:02 2014 Return-Path: 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 7842D1A8A66; Thu, 28 Aug 2014 13:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 h2fruqCl8Gr6; Thu, 28 Aug 2014 13:44:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE0B1A8A50; Thu, 28 Aug 2014 13:44:55 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7SKijKK075270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Aug 2014 15:44:47 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BC6684C@MX15A.corp.emc.com> Date: Thu, 28 Aug 2014 15:44:44 -0500 X-Mao-Original-Outgoing-Id: 430951484.843938-e6ca55b6c32d22f77b72f7e8eee4c77b Content-Transfer-Encoding: 7bit Message-Id: <4AEE93CB-788D-4A38-8A30-AD89D22C6377@nostrum.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BC6682D@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712077BC6684C@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/1JDfiYLOUiKoGEGQveWO3O5ES4Q Cc: "dart@ietf.org" , "avt@ietf.org WG \(avt@ietf.org\)" , "Colin Perkins \(csp@csperkins.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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:44:58 -0000 That works for me, thanks! On Aug 28, 2014, at 3:36 PM, Black, David wrote: > Minor edit to proposed text below: > > OLD > 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. > NEW > 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 with media similar to the RTP traffic > that it receives. > > Thanks, > --David > > >> -----Original Message----- >> From: Black, David >> Sent: Thursday, August 28, 2014 3:45 PM >> To: dart@ietf.org; avt@ietf.org WG (avt@ietf.org) >> Cc: Black, David; Colin Perkins (csp@csperkins.org); ben@nostrum.com >> Subject: DART dscp-rtp draft: Proposed RTCP text >> >> 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 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. >> 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. >> >> 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. >> >> Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer >> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> david.black@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >> > From nobody Thu Aug 28 13:59:33 2014 Return-Path: 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 C5C381A01E2; Thu, 28 Aug 2014 13:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 mo6wazB3t0fY; Thu, 28 Aug 2014 13:59:09 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1681A01D0; Thu, 28 Aug 2014 13:59:09 -0700 (PDT) Received: from [81.187.2.149] (port=44391 helo=[192.168.0.22]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XN6mg-0005HN-Gk; Thu, 28 Aug 2014 21:59:07 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BC6682D@MX15A.corp.emc.com> Date: Thu, 28 Aug 2014 21:59:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4DF64F47-D5DF-4202-9E7E-9CF570C840B3@csperkins.org> References: <8D3D17ACE214DC429325B2B98F3AE712077BC6682D@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/N2-PLOhoQ7ubw_7uJKe7NLnwskY Cc: "ben@nostrum.com" , "dart@ietf.org" , "avt@ietf.org WG \(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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:59:15 -0000 On 28 Aug 2014, at 20:45, Black, David 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: >=20 > 5.4. DiffServ and RTCP >=20 > 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).=20 You might also add something along the lines of =93If 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.=94=20 > 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=92t think this is a problem. The media doesn=92t 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. >=20 > 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 =93received RTP streams=94, since it=92s 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 >=20 > [... snip ...] >=20 > 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 =93Each SSRC should use a single DSCP for RTCP =85 used by RTP = packets that are or would be sent by that SSRC=85=94? Just =93sender" = 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. --=20 Colin Perkins http://csperkins.org/ From nobody Fri Aug 29 03:48:51 2014 Return-Path: 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 734B61A007E for ; Fri, 29 Aug 2014 03:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 kWAnMwpBHVlD for ; Fri, 29 Aug 2014 03:48:48 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 10FE41A0051 for ; Fri, 29 Aug 2014 03:48:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 69C397C3F0E; Fri, 29 Aug 2014 12:48:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rN47lL69oxg; Fri, 29 Aug 2014 12:48:43 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:c057:dbf2:750:a67f] (unknown [IPv6:2001:470:de0a:27:c057:dbf2:750:a67f]) by mork.alvestrand.no (Postfix) with ESMTPSA id EA19D7C3E5B; Fri, 29 Aug 2014 12:48:42 +0200 (CEST) Message-ID: <54005A89.1030606@alvestrand.no> Date: Fri, 29 Aug 2014 12:48:41 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ben Campbell , "Black, David" References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/5ugORoGH4WtUpPwgnYHlz9TVneo Cc: "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 10:48:50 -0000 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). On 08/28/2014 10:25 PM, Ben Campbell wrote: > Okay, works for me. > > Thanks! > > Ben. > > On Aug 28, 2014, at 3:15 PM, Black, David wrote: > >>> 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 >> >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@nostrum.com] >>> Sent: Thursday, August 28, 2014 3:44 PM >>> To: Black, David; Harald Tveit Alvestrand >>> Cc: dart@ietf.org >>> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >>> >>> (as chair) >>> >>> On Aug 28, 2014, at 1:12 PM, Black, David wrote: >>> >>>> [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. >>> 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 nobody Fri Aug 29 08:15:25 2014 Return-Path: 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 3D5DA1A047A for ; Fri, 29 Aug 2014 08:15:01 -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 WlqrBvs7dmOG for ; Fri, 29 Aug 2014 08:14:56 -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 9B1F31A0458 for ; Fri, 29 Aug 2014 08:14:56 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7TFEn7w030760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2014 11:14:51 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s7TFEn7w030760 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409325292; bh=PEano3md3UqIxFx/59Bv6QGQJzI=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ilZBOf59VSLc987swQoqkaIrfli/WNRCDx1QFODay6AsD1Hxmpf3qSFVZ3NWGot6r tUbXkFP8JpTHoPPu5gXVbQZhiMY+Q15BOnfFElzIIKgDwKSOYFyV8REouT0WB5Lk2G tRQiNURYa/9pC3vJHANc544VC046fzOJOzIU2Z08= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s7TFEn7w030760 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd02.lss.emc.com (RSA Interceptor); Fri, 29 Aug 2014 11:14:31 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7TFEdrU026636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Aug 2014 11:14:41 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Fri, 29 Aug 2014 11:14:40 -0400 From: "Black, David" To: Harald Alvestrand , Ben Campbell Date: Fri, 29 Aug 2014 11:14:38 -0400 Thread-Topic: [Dart] draft-dart-dscp-rtp - way forward Thread-Index: Ac/DdtV0+JRXfxCvRoqaimKY/SePGwAJGdhw Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> <54005A89.1030606@alvestrand.no> In-Reply-To: <54005A89.1030606@alvestrand.no> 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: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/briS_0eJ5B93puQXCC60s0n4OeA Cc: "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 15:15:02 -0000 Harald, I'm about to submit a -05 with the indication that the single DSCP recommen= dation 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 weeken= d=20 if you can quickly convince Colin. Thanks, --David > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Friday, August 29, 2014 6:49 AM > To: Ben Campbell; Black, David > Cc: dart@ietf.org > Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >=20 > I think the text in -04 looks reasonable. >=20 > I would like to do two things: >=20 > - 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." >=20 > - 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. >=20 > 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). >=20 >=20 > On 08/28/2014 10:25 PM, Ben Campbell wrote: > > Okay, works for me. > > > > Thanks! > > > > Ben. > > > > On Aug 28, 2014, at 3:15 PM, Black, David wrote: > > > >>> 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 bel= ieves > to > >>> be as complete is it's going to get. > >> In private discussion, both Harald and I favored saying less (rather t= han > 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 > >> > >>> -----Original Message----- > >>> From: Ben Campbell [mailto:ben@nostrum.com] > >>> Sent: Thursday, August 28, 2014 3:44 PM > >>> To: Black, David; Harald Tveit Alvestrand > >>> Cc: dart@ietf.org > >>> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward > >>> > >>> (as chair) > >>> > >>> On Aug 28, 2014, at 1:12 PM, Black, David wrote= : > >>> > >>>> [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 noth= ing > >>>> --> 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. > >>> 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 bel= ieves > to > >>> be as complete is it's going to get. > >>> > >>> David, thoughts? > >>> > >>> Harald, do you care to comment further? From nobody Fri Aug 29 08:17:53 2014 Return-Path: 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" To: Colin Perkins 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" , "dart@ietf.org" , "avt@ietf.org WG \(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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >=20 > On 28 Aug 2014, at 20:45, Black, David wrote: > > Here's the proposed new section 5.4, with the RTCP multi-stream reporti= ng > > optimizations text moved into that new section from its current locatio= n > > 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. >=20 > This looks okay (the correction in your next message is good also). >=20 > You might also add something along the lines of "If the SDP bundle extens= ion > [cite] is used to negotiate sending multiple types of media in a single R= TP > 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." >=20 > > 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. >=20 > 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 se= en by > the media, so this is fine. >=20 > > 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. >=20 > This could maybe say "received RTP streams", since it's okay to use the r= tp- > multi-stream-optimisation if you send with different DSCPs (the optimisat= ion > is optimising how you send reports about what you receive). >=20 > > 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. >=20 > Perhaps "Each SSRC should use a single DSCP for RTCP ... used by RTP pack= ets > that are or would be sent by that SSRC..."? Just "sender" could be ambigu= ous, > since an endpoint could be a sender for several streams, each of which ha= s a > separate SSRC and could use a different DSCP. >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Fri Aug 29 08:25:26 2014 Return-Path: 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 02ABD1A0535; Fri, 29 Aug 2014 08:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 WHX_sm2j3obR; Fri, 29 Aug 2014 08:25:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBE61A04F8; Fri, 29 Aug 2014 08:25:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140829152520.18514.36324.idtracker@ietfa.amsl.com> Date: Fri, 29 Aug 2014 08:25:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/bXY43aKoj0LKtaxTeq9WstpcpVI Cc: dart@ietf.org Subject: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-05.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 15:25:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DiffServ Applied to Real-time Transports Working Group of the IETF. Title : Differentiated Services (DiffServ) and Real-time Communication Authors : David Black Paul Jones Filename : draft-ietf-dart-dscp-rtp-05.txt Pages : 27 Date : 2014-08-29 Abstract: This memo describes the interaction between Differentiated Services (DiffServ) network quality of service (QoS) functionality and real- time network communication, including communication based on the Real-time Transport Protocol (RTP). DiffServ is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different DiffServ Code Points (DSCPs). WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple. Use of different DSCPs to obtain different QoS treatments within a single network 5-tuple, the results (e.g., reordering) may cause transport protocol interactions, particularly with congestion control functionality. In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of these DiffServ aspects for real-time network communication, including WebRTC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dart-dscp-rtp-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 29 08:52:22 2014 Return-Path: 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 7527E1A05D1 for ; Fri, 29 Aug 2014 08:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 w8HexVDC3vP2 for ; Fri, 29 Aug 2014 08:52:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B491A0537 for ; Fri, 29 Aug 2014 08:52:18 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7TFpnxM075990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Aug 2014 10:51:50 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> Date: Fri, 29 Aug 2014 10:51:48 -0500 X-Mao-Original-Outgoing-Id: 431020308.141178-f863c4b20506c74f340a0b8328ddeeea Content-Transfer-Encoding: quoted-printable Message-Id: <98430F26-7F61-447C-B374-D8CFA56FB1D0@nostrum.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> <54005A89.1030606@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> To: "Black, David" , Harald Tveit Alvestrand , "Colin Perkins (csp@csperkins.org)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/cmRrkXoVYy8zqdiuBUaBOe8wti8 Cc: "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 15:52:20 -0000 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 wrote: > Harald, >=20 > 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=20 > if you can quickly convince Colin. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Friday, August 29, 2014 6:49 AM >> To: Ben Campbell; Black, David >> Cc: dart@ietf.org >> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >>=20 >> I think the text in -04 looks reasonable. >>=20 >> I would like to do two things: >>=20 >> - 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." >>=20 >> - 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. >>=20 >> 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). >>=20 >>=20 >> On 08/28/2014 10:25 PM, Ben Campbell wrote: >>> Okay, works for me. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>> On Aug 28, 2014, at 3:15 PM, Black, David = wrote: >>>=20 >>>>> 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. >>>>=20 >>>> Thanks, >>>> --David >>>>=20 >>>>> -----Original Message----- >>>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>>> Sent: Thursday, August 28, 2014 3:44 PM >>>>> To: Black, David; Harald Tveit Alvestrand >>>>> Cc: dart@ietf.org >>>>> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >>>>>=20 >>>>> (as chair) >>>>>=20 >>>>> On Aug 28, 2014, at 1:12 PM, Black, David = wrote: >>>>>=20 >>>>>> [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. >>>>>>=20 >>>>>> --> 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. >>>>> I have mixed feelings on this. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> David, thoughts? >>>>>=20 >>>>> Harald, do you care to comment further? >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Fri Aug 29 08:52:23 2014 Return-Path: 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 E155A1A0537 for ; Fri, 29 Aug 2014 08:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 B2eAW9R4Z8n7 for ; Fri, 29 Aug 2014 08:52:17 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF381A0547 for ; Fri, 29 Aug 2014 08:52:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 20BD47C3F7A; Fri, 29 Aug 2014 17:52:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkl53eDlyRlC; Fri, 29 Aug 2014 17:52:14 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:40b7:5f40:a179:6443] (unknown [IPv6:2001:470:de0a:27:40b7:5f40:a179:6443]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6C3837C3F6A; Fri, 29 Aug 2014 17:52:14 +0200 (CEST) Message-ID: <5400A1AB.6000600@alvestrand.no> Date: Fri, 29 Aug 2014 17:52:11 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Black, David" , Ben Campbell References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> <54005A89.1030606@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/o41g9ipLWjxrD1RpLQFi-TB8B58 Cc: "dart@ietf.org" , colin Perkins Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 15:52:21 -0000 On 08/29/2014 05:14 PM, Black, David wrote: > 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. 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? > > Thanks, > --David > >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Friday, August 29, 2014 6:49 AM >> To: Ben Campbell; Black, David >> Cc: dart@ietf.org >> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >> >> 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). >> >> >> On 08/28/2014 10:25 PM, Ben Campbell wrote: >>> Okay, works for me. >>> >>> Thanks! >>> >>> Ben. >>> >>> On Aug 28, 2014, at 3:15 PM, Black, David wrote: >>> >>>>> 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 >>>> >>>>> -----Original Message----- >>>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>>> Sent: Thursday, August 28, 2014 3:44 PM >>>>> To: Black, David; Harald Tveit Alvestrand >>>>> Cc: dart@ietf.org >>>>> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >>>>> >>>>> (as chair) >>>>> >>>>> On Aug 28, 2014, at 1:12 PM, Black, David wrote: >>>>> >>>>>> [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. >>>>> 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 nobody Fri Aug 29 09:05:07 2014 Return-Path: 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 69C3D1A0659 for ; Fri, 29 Aug 2014 09:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9dLMEHrBY0Z2 for ; Fri, 29 Aug 2014 09:05:03 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763B61A0658 for ; Fri, 29 Aug 2014 09:05:03 -0700 (PDT) Received: from [130.209.247.112] (port=57215 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XNOfc-0002J3-4O; Fri, 29 Aug 2014 17:05:00 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <5400A1AB.6000600@alvestrand.no> Date: Fri, 29 Aug 2014 17:04:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6521A08A-30A9-4805-9B84-41EC4376BDF6@csperkins.org> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> <54005A89.1030606@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> <5400A1AB.6000600@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/q6mAvLe2yJfGKkNlT7rDHLRHJoI Cc: Ben Campbell , "Black, David" , "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 16:05:06 -0000 On 29 Aug 2014, at 16:52, Harald Alvestrand = wrote: > On 08/29/2014 05:14 PM, Black, David wrote: >> Harald, >>=20 >> I=92m 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=92m about to vanish for about 3 weeks, but = could put in a revised -06 over the weekend if you can quickly convince = Colin. >=20 > Explicitly pinging Colin - Colin, are you arguing that the sentence >=20 > 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. >=20 > should stay in the draft? I was, but thinking again, I=92m not so sure.=20 > I think this recommendation is wrong. >=20 > 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. >=20 > 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=92s 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=92m not sure that=92s the sentence = we have above.=20 --=20 Colin Perkins http://csperkins.org/ From nobody Fri Aug 29 11:27:48 2014 Return-Path: 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 C49B91A0ADC for ; Fri, 29 Aug 2014 11:27:41 -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 kjUxJxlmAFNm for ; Fri, 29 Aug 2014 11:27:39 -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 2A61D1A6F9E for ; Fri, 29 Aug 2014 11:23:42 -0700 (PDT) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7TINXZt016420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2014 14:23:34 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s7TINXZt016420 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409336614; bh=UdAul6DlSn5e9ebXsMZFgKnw2ro=; h=From:To:CC:Date:Subject:Message-ID:In-Reply-To:Content-Type: Content-Transfer-Encoding:MIME-Version; b=p+KG2ZCUA9Ie0jg8czZG7SNoDuphnalJs8ptaaT+/NxmmP3AKeJKi6+GUdWXX5Ro9 MVyXRUcgFN5ReG8lSoBRhh0mQoT7EiOz/gcgusTK5IyjIznH4ORwPLdP1MK8xKOTIs YWaeAL0Bw1NTApqphTiROYdUi7mYvxVIqvcd5uks= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s7TINXZt016420 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd01.lss.emc.com (RSA Interceptor); Fri, 29 Aug 2014 14:23:12 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7TINI6m018254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Aug 2014 14:23:18 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Fri, 29 Aug 2014 14:23:18 -0400 From: "Black, David" To: "'csp@csperkins.org'" , "'harald@alvestrand.no'" Date: Fri, 29 Aug 2014 14:23:17 -0400 Thread-Topic: [Dart] draft-dart-dscp-rtp - way forward Thread-Index: Ac/Dov8H7FjQ6Sl4SLyLR6d/gb/2EwAE06o2 Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077B9A4854@MX15A.corp.emc.com> In-Reply-To: <6521A08A-30A9-4805-9B84-41EC4376BDF6@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/sPHD0dSrTqMKmcujza_9q19Vrkk Cc: "'ben@nostrum.com'" , "Black, David" , "'dart@ietf.org'" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 18:27:41 -0000 DQpJZiBEU0NQIGNob2ljZSBmb3IgdGhlIHJlZHVjZWQgbnVtYmVyIG9mIHJlcG9ydHMgaXMgb3J0 aG9nb25hbCB0byB1c2Ugb2YgdGhlIFJUQ1AgbXVsdGktc3RyZWFtIG9wdGltaXNhdGlvbiwgdGhl biBJIHRoaW5rIHRoZSBEQVJUIGRyYWZ0IHBhcmFncmFwaCBvbiB0aGF0IG9wdGltaXNhdGlvbiBj YW4gYmUgcmVtb3ZlZC4NCg0KQ29uc2lkZXJhdGlvbiBvZiB0aGUgRFNDUCB0aGF0IHdpbGwgYmUg dXNlZCB0byBzZW5kIHRoZSByZXBvcnRzIG1heSBiZSBhIGNvbnNpZGVyYXRpb24gaW4gc2VsZWN0 aW5nIHRoZSBTU1JDIHRoYXQgcmVwb3J0cyBvbiBiZWhhbGYgb2YgdGhlIHJlcG9ydGluZyBncm91 cCAoYXMgd2UndmUgdGllZCB0aGUgRFNDUCBmb3IgUlRDUCB0byB0aGUgb3JpZ2luYXRpbmcgU1NS QyksIGJ1dCB0aGF0J3MgcHJvYmFibHkgYmV0dGVyIGFkZHJlc3NlZCAoaWYgcmVsZXZhbnQpIGlu IHRoZSBtdWx0aS1zdHJlYW0gb3B0aW1pc2F0aW9uIGRyYWZ0Lg0KDQpGdXJ0aGVyIGNvbW1lbnRz Pw0KDQpUaGFua3MsIC0tRGF2aWQgKysrU2VudCBmcm9tIEJsYWNrYmVycnkNCg0KLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogQ29saW4gUGVya2lucyBbbWFpbHRvOmNzcEBjc3Bl cmtpbnMub3JnXQ0KU2VudDogRnJpZGF5LCBBdWd1c3QgMjksIDIwMTQgMTI6MDQgUE0KVG86IEhh cmFsZCBBbHZlc3RyYW5kIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubz4NCkNjOiBCbGFjaywgRGF2aWQ7 IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPjsgZGFydEBpZXRmLm9yZyA8ZGFydEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbRGFydF0gZHJhZnQtZGFydC1kc2NwLXJ0cCAtIHdheSBmb3J3 YXJkDQoNCk9uIDI5IEF1ZyAyMDE0LCBhdCAxNjo1MiwgSGFyYWxkIEFsdmVzdHJhbmQgPGhhcmFs ZEBhbHZlc3RyYW5kLm5vPiB3cm90ZToNCj4gT24gMDgvMjkvMjAxNCAwNToxNCBQTSwgQmxhY2ss IERhdmlkIHdyb3RlOg0KPj4gSGFyYWxkLA0KPj4gDQo+PiBJ4oCZbSBhYm91dCB0byBzdWJtaXQg YSAtMDUgd2l0aCB0aGUgaW5kaWNhdGlvbiB0aGF0IHRoZSBzaW5nbGUgRFNDUCByZWNvbW1lbmRh dGlvbiBmb3IgU0NUUCBhbmQgRENDUCBtYXkgYmUgcmV2aXNlZC4gIFRoZSBSVENQIG11bHRpLXN0 cmVhbSBvcHRpbWlzYXRpb24gdGV4dCB3aWxsIHN0aWxsIGJlIGluIHRoZXJlIHdpdGggQ29saW4n cyBjbGFyaWZpY2F0aW9uIGFib3V0ICJyZWNlaXZlZCIgc3RyZWFtcy4gIEnigJltIGFib3V0IHRv IHZhbmlzaCBmb3IgYWJvdXQgMyB3ZWVrcywgYnV0IGNvdWxkIHB1dCBpbiBhIHJldmlzZWQgLTA2 IG92ZXIgdGhlIHdlZWtlbmQgaWYgeW91IGNhbiBxdWlja2x5IGNvbnZpbmNlIENvbGluLg0KPiAN Cj4gRXhwbGljaXRseSBwaW5naW5nIENvbGluIC0gQ29saW4sIGFyZSB5b3UgYXJndWluZyB0aGF0 IHRoZSBzZW50ZW5jZQ0KPiANCj4gICBSVENQIG11bHRpLXN0cmVhbSByZXBvcnRpbmcgb3B0aW1p emF0aW9ucyBmb3IgYW4gUlRQIHNlc3Npb24NCj4gICBbSS1ELmlldGYtYXZ0Y29yZS1ydHAtbXVs dGktc3RyZWFtLW9wdGltaXNhdGlvbl0gYXNzdW1lIHRoYXQgdGhlIFJUUA0KPiAgIHN0cmVhbXMg aW52b2x2ZWQgZXhwZXJpZW5jZSB0aGUgc2FtZSBwYWNrZXQgbG9zcyBiZWhhdmlvci4gIFRoaXMN Cj4gICBtZWNoYW5pc20gaXMgaGlnaGx5IGluYXBwcm9wcmlhdGUgd2hlbiB0aGUgUlRQIHN0cmVh bXMgaW52b2x2ZWQgdXNlDQo+ICAgZGlmZmVyZW50IFBIQnMsIGV2ZW4gaWYgdGhvc2UgUEhCcyBk aWZmZXIgc29sZWx5IGluIGRyb3AgcHJlY2VkZW5jZS4NCj4gDQo+IHNob3VsZCBzdGF5IGluIHRo ZSBkcmFmdD8NCg0KSSB3YXMsIGJ1dCB0aGlua2luZyBhZ2FpbiwgSeKAmW0gbm90IHNvIHN1cmUu IA0KDQo+IEkgdGhpbmsgdGhpcyByZWNvbW1lbmRhdGlvbiBpcyB3cm9uZy4NCj4gDQo+IEkgY2Fu J3QgZmluZCBhbnl0aGluZyBpbiB5b3VyIGxhdGVzdCBtZXNzYWdlcyB0aGF0IHNwZWFrIHRvIHRo aXMgcGFydGljdWxhciBwb2ludC4NCj4gWW91J3JlIG9uZSBvZiB0aGUgYXV0aG9ycyBvZiAtbXVs dGktc3RyZWFtLCBzbyB5b3Ugc2hvdWxkIGJlIGFibGUgdG8gc3BlYWsgY2xlYXJseSB0byB0aGUg cG9pbnQuDQo+IA0KPiBDYW4geW91IGNsYXJpZnk/DQoNCklmIEkgaGF2ZSBzZXZlcmFsIFNTUkNz LCBhbmQgcmVjZWl2ZSBzZXZlcmFsIG1lZGlhIHN0cmVhbXMsIHRoZW4gcHJvdmlkZWQgZWFjaCBv ZiBteSBTU1JDcyBzZWVzIHRoZSBleGFjdCBzYW1lIHF1YWxpdHkgZm9yIGVhY2ggcmVjZWl2ZWQg c3RyZWFtLCB0aGVuICBJIGNhbiB1c2UgdGhlIG11bHRpLXN0cmVhbS1vcHRpbWlzYXRpb24gdG8g cmVkdWNlIHRoZSBudW1iZXIgb2YgUlRDUCBjcm9zcyByZXBvcnRzIEkgc2VuZC4gVGhlIG11bHRp LXN0cmVhbS1vcHRpbWlzYXRpb24gZHJhZnQgc2F5cyB0aGF0IGFscmVhZHksIGFuZCBpdOKAmXMg bm90IGNsZWFyIHRoYXQgdGhlIERBUlQgZHJhZnRzIG5lZWRzIHRvIHNheSBhbnl0aGluZyBmdXJ0 aGVyIG9uIHRoZSB0b3BpYy4NCg0KV2hldGhlciBJIHVzZSB0aGUgc2FtZSBEU0NQIGZvciBhbGwg UlRDUCByZXBvcnRzIEkgc2VuZCBpcywgSSB0aGluaywgb3J0aG9nb25hbCB0byB3aGV0aGVyIEkg dXNlIHRoZSBtdWx0aS1zdHJlYW0tb3B0aW1pc2F0aW9uLiBUaGUgZGFydCBkcmFmdCBzaG91bGQg cG9zc2libHkgc2F5IHRoYXQsIGJ1dCBJ4oCZbSBub3Qgc3VyZSB0aGF04oCZcyB0aGUgc2VudGVu Y2Ugd2UgaGF2ZSBhYm92ZS4gDQoNCg0KLS0gDQpDb2xpbiBQZXJraW5zDQpodHRwOi8vY3NwZXJr aW5zLm9yZy8NCg0KDQoNCg== From nobody Fri Aug 29 11:32:52 2014 Return-Path: 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 067281A1F04 for ; Fri, 29 Aug 2014 11:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 3r6uxTtPOq2e for ; Fri, 29 Aug 2014 11:32:48 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1521A6F39 for ; Fri, 29 Aug 2014 11:29:07 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7TISghq089744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Aug 2014 13:28:43 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077B9A4854@MX15A.corp.emc.com> Date: Fri, 29 Aug 2014 13:28:42 -0500 X-Mao-Original-Outgoing-Id: 431029722.232679-58465f718bd11636cd2c7bb7eb40a026 Content-Transfer-Encoding: quoted-printable Message-Id: <8AA3993F-CAEC-4DFA-B09F-0A6856498DFE@nostrum.com> References: <8D3D17ACE214DC429325B2B98F3AE712077B9A4854@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/Pn0QpmsDjSJP3tQO7ymlMkwRg44 Cc: Harald Tveit Alvestrand , "dart@ietf.org" , "csp@csperkins.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 18:32:50 -0000 On Aug 29, 2014, at 1:23 PM, Black, David wrote: >=20 > 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. >=20 > 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. >=20 > Further comments? =46rom the conversation so far, I agree. From nobody Fri Aug 29 12:29:25 2014 Return-Path: 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 155B11A0371 for ; Fri, 29 Aug 2014 12:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 aPBP1BDHRnQ6 for ; Fri, 29 Aug 2014 12:29:21 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7131A0104 for ; Fri, 29 Aug 2014 12:29:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A5B9D7C3F9C; Fri, 29 Aug 2014 21:29:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQDsQg+R8IsO; Fri, 29 Aug 2014 21:29:17 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:40b7:5f40:a179:6443] (unknown [IPv6:2001:470:de0a:27:40b7:5f40:a179:6443]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4E68A7C3A34; Fri, 29 Aug 2014 21:29:17 +0200 (CEST) Message-ID: <5400D48A.30306@alvestrand.no> Date: Fri, 29 Aug 2014 21:29:14 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Colin Perkins References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> <54005A89.1030606@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> <5400A1AB.6000600@alvestrand.no> <6521A08A-30A9-4805-9B84-41EC4376BDF6@csperkins.org> In-Reply-To: <6521A08A-30A9-4805-9B84-41EC4376BDF6@csperkins.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/QbcJc5XSE0l8YEfjAts9q2Usw0w Cc: Ben Campbell , "Black, David" , "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 19:29:24 -0000 On 08/29/2014 06:04 PM, Colin Perkins wrote: > On 29 Aug 2014, at 16:52, Harald Alvestrand wrote: >> On 08/29/2014 05:14 PM, Black, David wrote: >>> Harald, >>> >>> Im 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. Im about to vanish for about 3 weeks, but could put in a revised -06 over the weekend 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 was, but thinking again, Im not so sure. > >> 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? > 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 its 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 Im not sure thats the sentence we have above. > > 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 nobody Fri Aug 29 13:10:21 2014 Return-Path: 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 DEE7C1A070F for ; Fri, 29 Aug 2014 13:10:19 -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 UZ4Zk5xitAkd for ; Fri, 29 Aug 2014 13:10:18 -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 24AB41A0651 for ; Fri, 29 Aug 2014 13:10:17 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7TKA5ej007344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2014 16:10:06 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7TKA5ej007344 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409343006; bh=EjoCU9pYMk2dl5c4owPakzyz9Dg=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ipHkWijOXU0gljXau7PF6FpDyE75/JlwMeLtJ/Sw3v80wPzr8Q5CUxitINPkH9jgQ mf8huCcpph+QHCf/2TYooRpQP+j9ngthSr6zhinoF60xhg6vg1BYrIQs/g/YkfgHeL 5R4vBNkidUFtOwoM64h7+QP+lOwoiaqC6Y9xRrRA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7TKA5ej007344 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd55.lss.emc.com (RSA Interceptor); Fri, 29 Aug 2014 16:09:40 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7TK9mjW023762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Aug 2014 16:09:49 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Fri, 29 Aug 2014 16:09:48 -0400 From: "Black, David" To: Harald Alvestrand , Colin Perkins Date: Fri, 29 Aug 2014 16:09:43 -0400 Thread-Topic: [Dart] draft-dart-dscp-rtp - way forward Thread-Index: Ac/Dv4rOpmeWfzq1SimAzI3/mkrHGgABQhMQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BC6699A@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> <54005A89.1030606@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> <5400A1AB.6000600@alvestrand.no> <6521A08A-30A9-4805-9B84-41EC4376BDF6@csperkins.org> <5400D48A.30306@alvestrand.no> In-Reply-To: <5400D48A.30306@alvestrand.no> 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: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/OtTG35iBDn6qG9KdKMELKpKrYjg Cc: Ben Campbell , "Black, David" , "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 20:10:20 -0000 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 interac= tion of DiffServ and RTCP multi-stream optimization will be dealt with in the dr= aft 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 > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Friday, August 29, 2014 3:29 PM > To: Colin Perkins > Cc: Ben Campbell; Black, David; dart@ietf.org > Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >=20 > On 08/29/2014 06:04 PM, Colin Perkins wrote: > > On 29 Aug 2014, at 16:52, Harald Alvestrand wrot= e: > >> On 08/29/2014 05:14 PM, Black, David wrote: > >>> 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 > 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. > >> 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 RT= P > >> 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 was, but thinking again, I'm not so sure. > > > >> I think this recommendation is wrong. > >> > >> I can't find anything in your latest messages that speak to this parti= cular > point. > >> You're one of the authors of -multi-stream, so you should be able to s= peak > clearly to the point. > >> > >> Can you clarify? > > If I have several SSRCs, and receive several media streams, then provid= ed > each of my SSRCs sees the exact same quality for each received stream, th= en 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, an= d > 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 ab= ove. > > > > > 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. >=20 > I'd be sad if that was the case, *especially* if we can't figure out any > reason to make that recommendation. From nobody Fri Aug 29 13:14:14 2014 Return-Path: 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 C30C41A056D for ; Fri, 29 Aug 2014 13:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 QNIQnItgs-Gx for ; Fri, 29 Aug 2014 13:14:11 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 01C121A0537 for ; Fri, 29 Aug 2014 13:14:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 3D6047C3F89; Fri, 29 Aug 2014 22:14:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmSw1AT98Yuj; Fri, 29 Aug 2014 22:14:09 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:1965:7d1f:23fa:58ce] (unknown [IPv6:2001:470:de0a:27:1965:7d1f:23fa:58ce]) by mork.alvestrand.no (Postfix) with ESMTPSA id BEF297C3E1F; Fri, 29 Aug 2014 22:14:08 +0200 (CEST) Message-ID: <5400DF0F.6060704@alvestrand.no> Date: Fri, 29 Aug 2014 22:14:07 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Black, David" , Colin Perkins References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> <54005A89.1030606@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> <5400A1AB.6000600@alvestrand.no> <6521A08A-30A9-4805-9B84-41EC4376BDF6@csperkins.org> <5400D48A.30306@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6699A@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BC6699A@MX15A.corp.emc.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dart/j7E6VXIQ8mjbjfxm-ER0tN-a9Mc Cc: Ben Campbell , "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 20:14:13 -0000 On 08/29/2014 10:09 PM, Black, David wrote: > 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 :-). Looks good to me! > > Thanks, > --David > >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Friday, August 29, 2014 3:29 PM >> To: Colin Perkins >> Cc: Ben Campbell; Black, David; dart@ietf.org >> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >> >> On 08/29/2014 06:04 PM, Colin Perkins wrote: >>> On 29 Aug 2014, at 16:52, Harald Alvestrand wrote: >>>> On 08/29/2014 05:14 PM, Black, David wrote: >>>>> 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 >> 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. >>>> 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 was, but thinking again, I'm not so sure. >>> >>>> 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? >>> 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. >>> >> 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. -- Surveillance is pervasive. Go Dark. From nobody Fri Aug 29 13:17:34 2014 Return-Path: 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 B40841A6F67 for ; Fri, 29 Aug 2014 13:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 NQJFGX3lYiRB for ; Fri, 29 Aug 2014 13:17:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36A21A0AFB for ; Fri, 29 Aug 2014 13:17:24 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7TKGw3C008390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Aug 2014 15:17:00 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077BC6699A@MX15A.corp.emc.com> Date: Fri, 29 Aug 2014 15:16:58 -0500 X-Mao-Original-Outgoing-Id: 431036218.742503-160a0d0ae1651283c3147c2544ec76e4 Content-Transfer-Encoding: quoted-printable Message-Id: <66D9B374-9647-4399-8467-71258705B525@nostrum.com> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> <54005A89.1030606@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> <5400A1AB.6000600@alvestrand.no> <6521A08A-30A9-4805-9B84-41EC4376BDF6@csperkins.org> <5400D48A.30306@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6699A@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/s7ar86FqFc2sqNOlml_9H0STC3s Cc: Harald Tveit Alvestrand , "dart@ietf.org" , Colin Perkins Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 20:17:30 -0000 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. On Aug 29, 2014, at 3:09 PM, Black, David wrote: > Ok, I see a range of views from skepticism to outright opposition ... >=20 > 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. >=20 > 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 :-). >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Friday, August 29, 2014 3:29 PM >> To: Colin Perkins >> Cc: Ben Campbell; Black, David; dart@ietf.org >> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >>=20 >> On 08/29/2014 06:04 PM, Colin Perkins wrote: >>> On 29 Aug 2014, at 16:52, Harald Alvestrand = wrote: >>>> On 08/29/2014 05:14 PM, Black, David wrote: >>>>> Harald, >>>>>=20 >>>>> 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. >>>> Explicitly pinging Colin - Colin, are you arguing that the sentence >>>>=20 >>>> 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. >>>>=20 >>>> should stay in the draft? >>> I was, but thinking again, I'm not so sure. >>>=20 >>>> I think this recommendation is wrong. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>>=20 >> 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. >>=20 >> I'd be sad if that was the case, *especially* if we can't figure out = any >> reason to make that recommendation. >=20 From nobody Fri Aug 29 13:20:18 2014 Return-Path: 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 E4CF71A6F59 for ; Fri, 29 Aug 2014 13:20:14 -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 HK9e1rBQJlpj for ; Fri, 29 Aug 2014 13:20:13 -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 4DA241A068D for ; Fri, 29 Aug 2014 13:20:10 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7TKK4Bf012692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2014 16:20:05 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s7TKK4Bf012692 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409343605; bh=o3FH4PRlLnFXWQWrAiQqeWyvmzU=; h=From:To:CC:Date:Subject:Message-ID:In-Reply-To:Content-Type: Content-Transfer-Encoding:MIME-Version; b=k9kbvsYCt2i4avEmk2ucm73AhEoWqwk+50J5arIVFhScZCcgtodsUAVxMR9TxorXE DJSomFvUpJKKZFItqqQU1piP5HuqaW06jy/ApDUyxnIXzCCWJ7tfi/wJ6Dba3PQdk/ /4uCeoKGlTaLNonXSXYL2dtRIER9CNSlsx8W5pv0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s7TKK4Bf012692 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd06.lss.emc.com (RSA Interceptor); Fri, 29 Aug 2014 16:19:45 -0400 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7TKK0H6017609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Aug 2014 16:20:00 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Fri, 29 Aug 2014 16:19:59 -0400 From: "Black, David" To: "'ben@nostrum.com'" Date: Fri, 29 Aug 2014 16:19:58 -0400 Thread-Topic: [Dart] draft-dart-dscp-rtp - way forward Thread-Index: Ac/DxkKcTuwXhF7PQ+uhqTCbDCWobgAAFhGK Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077B9A4855@MX15A.corp.emc.com> In-Reply-To: <66D9B374-9647-4399-8467-71258705B525@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/dart/3peUmbgkskrMR5Q5WgkAUwv7XyE Cc: "'harald@alvestrand.no'" , "'dart@ietf.org'" , "'csp@csperkins.org'" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 20:20:15 -0000 Correct!! Thanks, --David +++Sent from Blackberry ----- Original Message ----- From: Ben Campbell [mailto:ben@nostrum.com] Sent: Friday, August 29, 2014 04:16 PM=0A= To: Black, David Cc: Harald Tveit Alvestrand ; Colin Perkins ; dart@ietf.org Subject: Re: [Dart] draft-dart-dscp-rtp - way forward Thanks, David! Am I counting correctly that this would close the last substantive open iss= ue? If so, and if Harald and Colin confirm they are okay with the change, w= e should be able to request publication for the upcoming version, correct? (I see that Harald expressed support as I am typing this...) Thanks! Ben. On Aug 29, 2014, at 3:09 PM, Black, David wrote: > Ok, I see a range of views from skepticism to outright opposition ... >=20 > 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 inter= action > of DiffServ and RTCP multi-stream optimization will be dealt with in the = draft > about the latter. >=20 > 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 :-). >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Friday, August 29, 2014 3:29 PM >> To: Colin Perkins >> Cc: Ben Campbell; Black, David; dart@ietf.org >> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >>=20 >> On 08/29/2014 06:04 PM, Colin Perkins wrote: >>> On 29 Aug 2014, at 16:52, Harald Alvestrand wrot= e: >>>> On 08/29/2014 05:14 PM, Black, David wrote: >>>>> Harald, >>>>>=20 >>>>> 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 abou= t >> "received" streams. I'm about to vanish for about 3 weeks, but could pu= t in a >> revised -06 over the weekend if you can quickly convince Colin. >>>> Explicitly pinging Colin - Colin, are you arguing that the sentence >>>>=20 >>>> 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. >>>>=20 >>>> should stay in the draft? >>> I was, but thinking again, I'm not so sure. >>>=20 >>>> I think this recommendation is wrong. >>>>=20 >>>> I can't find anything in your latest messages that speak to this parti= cular >> point. >>>> You're one of the authors of -multi-stream, so you should be able to s= peak >> clearly to the point. >>>>=20 >>>> Can you clarify? >>> If I have several SSRCs, and receive several media streams, then provid= ed >> each of my SSRCs sees the exact same quality for each received stream, t= hen 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, a= nd >> it's not clear that the DART drafts needs to say anything further on the >> topic. >>>=20 >>> 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 draf= t >> should possibly say that, but I'm not sure that's the sentence we have a= bove. >>>=20 >>>=20 >> 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. >>=20 >> I'd be sad if that was the case, *especially* if we can't figure out any >> reason to make that recommendation. >=20 From nobody Fri Aug 29 14:56:06 2014 Return-Path: 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 E35471A02E3 for ; Fri, 29 Aug 2014 14:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ad_K7RUev-an for ; Fri, 29 Aug 2014 14:56:04 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138311A02D7 for ; Fri, 29 Aug 2014 14:56:04 -0700 (PDT) Received: from [81.187.2.149] (port=46836 helo=[192.168.0.24]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XNU9H-0006iW-Ax; Fri, 29 Aug 2014 22:56:01 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Colin Perkins X-Mailer: iPad Mail (11D257) In-Reply-To: <66D9B374-9647-4399-8467-71258705B525@nostrum.com> Date: Fri, 29 Aug 2014 22:55:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5D845428-3E6D-43AC-978E-4754C627FD69@csperkins.org> References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> <54005A89.1030606@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> <5400A1AB.6000600@alvestrand.no> <6521A08A-30A9-4805-9B84-41EC4376BDF6@csperkins.org> <5400D48A.30306@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6699A@MX15A.corp.emc.com> <66D9B374-9647-4399-8467-71258705B525@nostrum.com> To: Ben Campbell X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/dart/cx_txSFUhvAzRPrwiDSLmmeyDAo Cc: Harald Tveit Alvestrand , "Black, David" , "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 21:56:06 -0000 Without having seen the submitted version, this sounds okay. --=20 Colin Perkins http://csperkins.org/ > On 29 Aug 2014, at 21:16, Ben Campbell wrote: >=20 > Thanks, David! >=20 > Am I counting correctly that this would close the last substantive open is= sue? If so, and if Harald and Colin confirm they are okay with the change, w= e should be able to request publication for the upcoming version, correct? >=20 > (I see that Harald expressed support as I am typing this...) >=20 > Thanks! >=20 > Ben. >=20 >> On Aug 29, 2014, at 3:09 PM, Black, David wrote: >>=20 >> Ok, I see a range of views from skepticism to outright opposition ... >>=20 >> 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 inter= action >> of DiffServ and RTCP multi-stream optimization will be dealt with in the d= raft >> about the latter. >>=20 >> 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 :-). >>=20 >> Thanks, >> --David >>=20 >>> -----Original Message----- >>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>> Sent: Friday, August 29, 2014 3:29 PM >>> To: Colin Perkins >>> Cc: Ben Campbell; Black, David; dart@ietf.org >>> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >>>=20 >>>> On 08/29/2014 06:04 PM, Colin Perkins wrote: >>>>> On 29 Aug 2014, at 16:52, Harald Alvestrand wro= te: >>>>>> On 08/29/2014 05:14 PM, Black, David wrote: >>>>>> Harald, >>>>>>=20 >>>>>> 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 abou= t >>> "received" streams. I'm about to vanish for about 3 weeks, but could pu= t in a >>> revised -06 over the weekend if you can quickly convince Colin. >>>>> Explicitly pinging Colin - Colin, are you arguing that the sentence >>>>>=20 >>>>> 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. >>>>>=20 >>>>> should stay in the draft? >>>> I was, but thinking again, I'm not so sure. >>>>=20 >>>>> I think this recommendation is wrong. >>>>>=20 >>>>> I can't find anything in your latest messages that speak to this parti= cular >>> point. >>>>> You're one of the authors of -multi-stream, so you should be able to s= peak >>> clearly to the point. >>>>>=20 >>>>> Can you clarify? >>>> If I have several SSRCs, and receive several media streams, then provid= ed >>> each of my SSRCs sees the exact same quality for each received stream, t= hen 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, a= nd >>> it's not clear that the DART drafts needs to say anything further on the= >>> topic. >>>>=20 >>>> 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 draf= t >>> should possibly say that, but I'm not sure that's the sentence we have a= bove. >>> 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. >>>=20 >>> I'd be sad if that was the case, *especially* if we can't figure out any= >>> reason to make that recommendation. >=20 From nobody Sat Aug 30 12:07:11 2014 Return-Path: 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 D4D921A0724; Sat, 30 Aug 2014 12:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 FCjhQfizWe8t; Sat, 30 Aug 2014 12:06:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A20BA1A0701; Sat, 30 Aug 2014 12:06:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140830190658.26481.9524.idtracker@ietfa.amsl.com> Date: Sat, 30 Aug 2014 12:06:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dart/-F-_r4xdkgQF7SjXvYfgx7Ip8A0 Cc: dart@ietf.org Subject: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-06.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 19:07:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DiffServ Applied to Real-time Transports Working Group of the IETF. Title : Differentiated Services (DiffServ) and Real-time Communication Authors : David Black Paul Jones Filename : draft-ietf-dart-dscp-rtp-06.txt Pages : 27 Date : 2014-08-30 Abstract: This memo describes the interaction between Differentiated Services (DiffServ) network quality of service (QoS) functionality and real- time network communication, including communication based on the Real-time Transport Protocol (RTP). DiffServ is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different DiffServ Code Points (DSCPs). WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple. Use of different DSCPs to obtain different QoS treatments within a single network 5-tuple, the results (e.g., reordering) may cause transport protocol interactions, particularly with congestion control functionality. In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of these DiffServ aspects for real-time network communication, including WebRTC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dart-dscp-rtp-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Aug 30 17:27:02 2014 Return-Path: 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 716451A6F02 for ; Sat, 30 Aug 2014 17:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 yhuAu8tc-FAH for ; Sat, 30 Aug 2014 17:26:58 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8A81A6F01 for ; Sat, 30 Aug 2014 17:26:58 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7V0QSds047892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 30 Aug 2014 19:26:30 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <5D845428-3E6D-43AC-978E-4754C627FD69@csperkins.org> Date: Sat, 30 Aug 2014 19:26:28 -0500 X-Mao-Original-Outgoing-Id: 431137588.121153-0a6f0b308adba7baacd7c706f187791d Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712077BC667DE@MX15A.corp.emc.com> <2B82DD06-83A4-4710-B614-16F5351A0A7F@nostrum.com> <8D3D17ACE214DC429325B2B98F3AE712077BC66841@MX15A.corp.emc.com> <54005A89.1030606@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6691C@MX15A.corp.emc.com> <5400A1AB.6000600@alvestrand.no> <6521A08A-30A9-4805-9B84-41EC4376BDF6@csperkins.org> <5400D48A.30306@alvestrand.no> <8D3D17ACE214DC429325B2B98F3AE712077BC6699A@MX15A.corp.emc.com> <66D9B374-9647-4399-8467-71258705B525@nostrum.com> <5D845428-3E6D-43AC-978E-4754C627FD69@csperkins.org> To: Colin Perkins , Harald Tveit Alvestrand X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/U-f-hXnqbu66GcP3b5DTbGfdKKE Cc: "Black, David" , "dart@ietf.org" Subject: Re: [Dart] draft-dart-dscp-rtp - way forward X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 00:27:00 -0000 Colin and Harald, I see David has submitted version 06. Can you verify that you are okay = with the language in this version?=20 Thanks! Ben. On Aug 29, 2014, at 4:55 PM, Colin Perkins wrote: > Without having seen the submitted version, this sounds okay. >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 >> On 29 Aug 2014, at 21:16, Ben Campbell wrote: >>=20 >> Thanks, David! >>=20 >> 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? >>=20 >> (I see that Harald expressed support as I am typing this...) >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>> On Aug 29, 2014, at 3:09 PM, Black, David = wrote: >>>=20 >>> Ok, I see a range of views from skepticism to outright opposition = ... >>>=20 >>> 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. >>>=20 >>> 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 :-). >>>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>> Sent: Friday, August 29, 2014 3:29 PM >>>> To: Colin Perkins >>>> Cc: Ben Campbell; Black, David; dart@ietf.org >>>> Subject: Re: [Dart] draft-dart-dscp-rtp - way forward >>>>=20 >>>>> On 08/29/2014 06:04 PM, Colin Perkins wrote: >>>>>> On 29 Aug 2014, at 16:52, Harald Alvestrand = wrote: >>>>>>> On 08/29/2014 05:14 PM, Black, David wrote: >>>>>>> Harald, >>>>>>>=20 >>>>>>> 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. >>>>>> Explicitly pinging Colin - Colin, are you arguing that the = sentence >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> should stay in the draft? >>>>> I was, but thinking again, I'm not so sure. >>>>>=20 >>>>>> I think this recommendation is wrong. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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. >>>> 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. >>>>=20 >>>> I'd be sad if that was the case, *especially* if we can't figure = out any >>>> reason to make that recommendation. >>=20 >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Sun Aug 31 12:07:18 2014 Return-Path: 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 204E51A8AF5 for ; Sun, 31 Aug 2014 12:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 HYrybcczmIAX for ; Sun, 31 Aug 2014 12:07:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82411A8AF1 for ; Sun, 31 Aug 2014 12:07:12 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7VJ7As5039232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 31 Aug 2014 14:07:11 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell Date: Sun, 31 Aug 2014 14:07:10 -0500 X-Mao-Original-Outgoing-Id: 431204830.064894-31758c22f9f2ea0b85709ab39105ce72 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140830190658.26481.9524.idtracker@ietfa.amsl.com> To: dart@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dart/5fJ0Y__GbYayxteYNFwPtXhtq0w Subject: [Dart] Progressing draft-ietf-dart-dscp-rtp-06.txt X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 19:07:16 -0000 Hi Everyone, I believe this version has closed all of the WGLC open issues, and fixed = most or all of the reported editorial nits. I'm going to request = publication. If anyone discovers additional issues, please continue to report them. = We can address those as part of the IETF last call. Thanks! Ben. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [Dart] I-D Action: draft-ietf-dart-dscp-rtp-06.txt > Date: August 30, 2014 at 2:06:58 PM CDT > To: i-d-announce@ietf.org > Cc: dart@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the DiffServ Applied to Real-time = Transports Working Group of the IETF. >=20 > Title : Differentiated Services (DiffServ) and = Real-time Communication > Authors : David Black > Paul Jones > Filename : draft-ietf-dart-dscp-rtp-06.txt > Pages : 27 > Date : 2014-08-30 >=20 > Abstract: > This memo describes the interaction between Differentiated Services > (DiffServ) network quality of service (QoS) functionality and real- > time network communication, including communication based on the > Real-time Transport Protocol (RTP). DiffServ is based on network > nodes applying different forwarding treatments to packets whose IP > headers are marked with different DiffServ Code Points (DSCPs). > WebRTC applications, as well as some conferencing applications, have > begun using the Session Description Protocol (SDP) bundle = negotiation > mechanism to send multiple traffic streams with different QoS > requirements using the same network 5-tuple. Use of different DSCPs > to obtain different QoS treatments within a single network 5-tuple, > the results (e.g., reordering) may cause transport protocol > interactions, particularly with congestion control functionality. = In > addition, DSCP markings may be changed or removed between the = traffic > source and destination. This memo covers the implications of these > DiffServ aspects for real-time network communication, including > WebRTC. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dart-dscp-rtp-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Sun Aug 31 13:05:55 2014 Return-Path: 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 88EDC1A9024 for ; Sun, 31 Aug 2014 13:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 iv8f7uzvNgKl for ; Sun, 31 Aug 2014 13:03:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D3C1A9025 for ; Sun, 31 Aug 2014 13:03:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: dart@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140831200343.7301.16642.idtracker@ietfa.amsl.com> Date: Sun, 31 Aug 2014 13:03:43 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/dart/51a8E9vNBrWCkABGhGGPdWPkdpg X-Mailman-Approved-At: Sun, 31 Aug 2014 13:05:54 -0700 Subject: [Dart] Milestones changed for dart WG X-BeenThere: dart@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 20:03:46 -0000 Changed milestone "Send Informational draft to IESG on DiffServ usage consideration", resolved as "Done", added draft-ietf-dart-dscp-rtp to milestone. URL: http://datatracker.ietf.org/wg/dart/charter/