From nobody Wed Aug 6 04:31:24 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6151AD8CA for ; Wed, 6 Aug 2014 04:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 ZoMJN1KIAWGP for ; Wed, 6 Aug 2014 04:31:20 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2651A000E for ; Wed, 6 Aug 2014 04:31:20 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id id10so3716924vcb.35 for ; Wed, 06 Aug 2014 04:31:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=k/0enseOj6vLO+j6Ea4z9VzSv06xCPbdMMoh0WVmjBo=; b=EqxM58RZ5Hge2xiz9hnyozPnkNyrRubA8zoF1Oogznfw0UA4QyQ8iNCbBCxJUov9C8 p0btDqxXL8x9Z49cpVBbEi5Sq46jvwPEC/wgGfDwiIjWX4F1QHruxphNUrpErW9+66p+ fEvua5USG3ammyyhok7E37rb8+99CumTMuGz1y2/AyrzLcAS1KycYwN14Kby03JVm7Wr j86LrqQXqqjYE4+bR5e4KHHTRknPUGRuN7SZwBqXfuQLxZBGkaKCkc9T807w8rQL1IRm fXKFVCmAg+GLIVxkDUChrBwB8eIHr9YmUEgC/yR/ush6ukcNoEh0+jIqw16cSEvTcqga Sdnw== X-Gm-Message-State: ALoCoQlQ3nfOKJTrlAgnq9RgOM+H2nUcJfDYRKOeWt41GHbmojRGPiRNSwwhMwNGYsaizo1GhsvO X-Received: by 10.52.27.80 with SMTP id r16mr63579vdg.91.1407324679261; Wed, 06 Aug 2014 04:31:19 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+xaearAYcHYjVBS1WwBmIAZmgtww== Date: Wed, 6 Aug 2014 07:31:16 -0400 Message-ID: <8dfa41a9e8ce1d92ee0da538020be93c@mail.gmail.com> To: avt@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/T6aVvD6HaA2Sc4lTUXDUdk9mrvM Subject: [AVTCORE] status of RFC 3611 errata 3795 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 11:31:22 -0000 Hi, Concerning the status of RFC 3611 errata 3795, I recommend that the proposed change be accepted. Original Text ------------- rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF Corrected Text -------------- rtcp-xr-attrib = "a=" "rtcp-xr" [ ":" xr-format *(SP xr-format)] CRLF RFC 3611's rtcp-xr-attrib ABNF conflicts with RFC 2327's (and RFC 4566's) attribute ABNF. RFC 2327 and RFC 4566 require a byte-string after the colon. RFC 3611 requires the colon even if no byte-string after it. This is causing interoperability issues. If you think rfc4566bis should somehow be modified to accommodate RFC 3611, the topic is currently being discussed within mmusic. http://www.ietf.org/mail-archive/web/mmusic/current/msg13668.html Thanks, Brett From nobody Thu Aug 7 15:50:14 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9631B27A7; Thu, 7 Aug 2014 15:50: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 l4LB4T25jzd5; Thu, 7 Aug 2014 15:50:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DF51A0B07; Thu, 7 Aug 2014 15:50:09 -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: <20140807225009.4486.88353.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 15:50:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/_6rpZnpCSoPMEBevZHiT6kWQYSs Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-topologies-update-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 22:50:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : RTP Topologies Authors : Magnus Westerlund Stephan Wenger Filename : draft-ietf-avtcore-rtp-topologies-update-03.txt Pages : 44 Date : 2014-08-07 Abstract: This document discusses point to point and multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This document is updated with additional topologies and is intended to replace RFC 5117. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-topologies-update/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-topologies-update-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 Thu Aug 7 16:14:38 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848041B2884 for ; Thu, 7 Aug 2014 16:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 SK6Vshc6l7Pc for ; Thu, 7 Aug 2014 16:14:34 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600C91B286C for ; Thu, 7 Aug 2014 16:14:34 -0700 (PDT) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB361.namprd07.prod.outlook.com (10.141.75.19) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 7 Aug 2014 23:14:28 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.136]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.136]) with mapi id 15.00.0995.014; Thu, 7 Aug 2014 23:14:28 +0000 From: Stephan Wenger To: "avt@ietf.org" Thread-Topic: Topologies-update, reply to Bo's review Thread-Index: AQHPspVWg15Q2HN36EeDlcGGcl3C3g== Date: Thu, 7 Aug 2014 23:14:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(164054003)(53754006)(24454002)(479174003)(199002)(189002)(79102001)(95666004)(19580405001)(74502001)(87936001)(66066001)(77096002)(92566001)(85852003)(106356001)(4396001)(2656002)(85306004)(99286002)(105586002)(110136001)(19580395003)(21056001)(74662001)(106116001)(77982001)(46102001)(229853001)(83322001)(101416001)(36756003)(76482001)(54356999)(20776003)(83072002)(81542001)(31966008)(81342001)(99396002)(92726001)(80022001)(86362001)(107046002)(2351001)(50986999)(2501001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB361; H:CO1PR07MB363.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/avt/i2d5k0VRCL4H8wPSd85oIVkCVPM Subject: [AVTCORE] Topologies-update, reply to Bo's review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 23:14:37 -0000 SGkgYWxsLA0KDQpZb3UgbWF5IGhhdmUgbm90aWNlZCB0aGF0IEkganVzdCBwb3N0ZWQgdmVyc2lv biAtMDMgb2YgdGhlDQp0b3BvbG9naWVzLXVwZGF0ZSBkcmFmdC4gIFRoZSBtYWluIGNoYW5nZXMg YXJlIGFsaWdubWVudCB3aXRoIHRoZQ0KdGVybWlub2xvZ3kgdXNlZCBpbiBhdnRleHShr3MgZ3Jv dXBpbmcgdGF4b25vbXkgZHJhZnQsIGFuZCBhIHJld3JpdGUgb2YNCnNlY3Rpb24gMy4xMCAoc3Bs aXQtY29tcG9uZW50IHRlcm1pbmFsKS4NCg0KQXMgcGVyIGd1aWRhbmNlIHJlY2VpdmVkIGluIFRv cm9udG8sIEkgZGlkIGluY2x1ZGUgY29weS1wYXN0ZXMgb2YgdGhvc2UNCmZldyBkZWZpbml0aW9u cyBvZiB0aGUgdGF4b25vbXkgZHJhZnQgcmVxdWlyZWQgaGVyZWluLCBzbyB0byBrZWVwIHRoZSB0 d28NCmRyYWZ0cyBpbmRlcGVuZGVudC4gIEhvd2V2ZXIsIEkgaGF2ZSBhbHNvIGFza2VkIHRoZSBS RkMgZWRpdG9yIHRvIHJlcGxhY2UNCnRob3NlIGRlZmluaXRpb25zIHdpdGggYSByZWZlcmVuY2Ug dG8gYSBmb3J0aGNvbWluZyB0YXhvbm9teS1SRkMsIGlmIHN1Y2gNCmNhbiBiZSBkb25lIHdpdGhv dXQgdW5kdWUgZGVsYXkuICBTZWUgc2VjdGlvbiAyLjIuDQoNClNlY3Rpb24gMy4xMCB3YXMgY2xv c2UgdG8gdW5wYXJzYWJsZS0tYXQgbGVhc3QgdmVyeSBjb25mdXNpbmctLXdoaWNoDQp0cmlnZ2Vy ZWQgdGhlIHJld3JpdGUuICBJIHRoaW5rIGl0oa9zIGJldHRlciBub3csIGJ1dCBpdCBjZXJ0YWlu bHkgbmVlZHMgYQ0KZnJlc2ggcmV2aWV3Lg0KDQpUb3dhcmRzIHRoZSBlbmQgb2YgdGhpcyBlbWFp bCwgZmluZCBteSByZXNwb25zZXMgdG8gQm8gQnVybWFuoa9zIHRob3JvdWdoDQpyZXZpZXcgb2Yg dmVyc2lvbiAtMDIsIHBvc3RlZCB0byB0aGlzIGxpc3Qgb24gNi8xMS8xNC4gIEkgaGFkIHByaXZh dGUNCmNvbW11bmljYXRpb24gd2l0aCBCbyBkdXJpbmcgdGhlIGVkaXRpbmcgcHJvY2VzcywgYW5k IGhloa9zIGhhcHB5IHdpdGggdGhlDQpyZXN1bHQgYW5kIGZvdW5kIGhpcyBwb2ludHMgYWRkcmVz c2VkLg0KDQpNeSBsaXN0IG9mIG9wZW4gaXNzdWVzIG9mIHRoaXMgZHJhZnQgaXMgbm93IGVtcHR5 LiAgV0dMQyB3b3VsZCBiZSBmaW5lDQp3aXRoIG1lLiAgUGxlYXNlIHJldmlldywgY29tbWVudCwg YW5kIGdldCB0aGlzIHRoaW5nIG91dCBvZiB0aGUgZG9vci4NCg0KVGhhbmtzLA0KU3RlcGhhbg0K DQpPbiA2LzExLzE0LCAyOjM5IEFNLCAiQm8gQnVybWFuIiA8Ym8uYnVybWFuQGVyaWNzc29uLmNv bT4gd3JvdGU6DQoNCkhpIGFsbCwNCg0KW0JvXSBJIHJldmlld2VkIHRoaXMgYXMgYSBwYXJ0IG9m IHRoZSBvbmdvaW5nIHVwZGF0ZSBvZiB0aGUgdGF4b25vbXkgZHJhZnQNCnRvDQp0cnkgdG8gYWxp Z24gdGhlbSwgYW5kIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50cyBvbiB0aGUNCnRvcG9sb2dp ZXMtdXBkYXRlLTAyOg0KKiBXaGF0IGlzIG1lYW50IHdpdGggIk1lZGlhIEZsb3ciIGluIDMuMi4x LjM7IGlzIGl0IGEgc2V0IG9mIFJUUCBTdHJlYW1zPw0KSW4gdGhhdCBjYXNlLCBkb2VzIHRoaXMg c2V0IGhhdmUgYW55IHNwZWNpZmljIGNoYXJhY3RlcmlzdGljcz8NCg0KW1N0V10NCg0KVGhlIGNv bW1lbnRzIHJlbGF0ZXMgdG8gdGhlIGRlc2NyaXB0aW9uIG9mIEZpZy4gMy4gIE5vLCB0aGUgqfht ZWRpYSBmbG93qfcNCmlzIHJlYWxseSBvbmx5IGEgc2luZ2xlIFJUUCBzdHJlYW0gKHdpdGhvdXQg RkVDKSB0byB3aGljaCBGRUMgaXMgYWRkZWQgYnkNCnRoZSB0cmFuc2xhdG9yLiAgVGhlIHJlbGV2 YW50IHBhcmFncmFwaCB3YXMgcG9vcmx5IGFuZCBvdmVybHkgYnJvYWRseQ0Kd3JpdHRlbiwgYW5k IEkgdGlnaHRlbmVkIHRoZSBsYW5ndWFnZS4NCg0KW0JvXQ0KKiAoQXQgbGVhc3QpIGluIDMuMi4y IGFuZCAzLjMuMywgdGhlIHRlcm0gImZsb3ciIGlzIHVzZWQgaW4gIlJUUCBmbG93IiBvcg0KInBh Y2tldCBmbG93IjsgaG93IGlzIHRoYXQgZGlmZmVyZW50IGZyb20gdGF4b25vbXkgUlRQIFN0cmVh bT8NCg0KW1N0V10NClZlcnkgZ29vZCBjYXRjaDsgdGhlIGxhbmd1YWdlIGhlcmUgKG1vc3RseSBm cm9tIDUxMTcpIHdhcyByZWFsbHkgaW4gbmVlZA0KdG8gYmUgdGlnaHRlbmVkIHVwLiAgSSBjaGVj a2VkIHRoZSB2YXJpb3VzIG9jY3VycmVuY2VzIG9mIKn4Zmxvd6n3LCBhbmQNCnJlcGxhY2VkIHRo ZW0gd2l0aCCp+FJUUCBzdHJlYW2p9yB3aGVyZSBhcHByb3ByaWF0ZS4gIFRoZSByZW1haW5pbmcg qfhmbG93qfdzDQphcmUgdHJhbnNwb3J0IGZsb3dzLCB3aGljaCBpcyBiYXNpY2FsbHkgdGhlIGZs b3cgb2YgcGFja2V0cyBpbiBhIHRyYW5zcG9ydA0KYXNzb2NpYXRpb24gKGZpdmUgdHVwbGUpLg0K DQpbQm9dDQoqIFRoZSB0ZXJtcyAidHJhbnNwb3J0IGZsb3ciIG9yIGp1c3QgImZsb3ciIGFyZSBo ZWF2aWx5IHVzZWQgaW4gMy40Ow0KYWdhaW4sIGFzIHdpdGggIk1lZGlhIEZsb3ciLCBpcyB0aGVy ZSBhbnkgc3BlY2lmaWMgZGlzdGluY3Rpb24gYXNzdW1lZCBpbg0KdGhpcyBiZXNpZGVzIHBvc3Np Ymx5IGJlaW5nIGEgc2V0IG9mIFJUUCBTdHJlYW1zPw0KDQpbU3RXXQ0KWWVzLCBpbiAzLjQsIHRy YW5zcG9ydCBmbG93IHJlZmVycyB0byBwYWNrZXRzIGdvaW5nIG92ZXIgYSA1IHR1cGxlLCBzZWUN CmFib3ZlLiAgSSBob3BlIHRoaXMgaXMgbm93IGNsZWFyIGZyb20gY29udGV4dC4NCg0KW0JvXQ0K KiBUaGUgdGVybSAiUlRQIG1lZGlhIHN0cmVhbSIgaXMgdXNlZCBpbiBtYW55IHBsYWNlczsgaXMg dGhlcmUgYW4NCmludGVuZGVkIHNwZWNpYWxpemF0aW9uIGNvbXBhcmVkIHRvIGEgKGdlbmVyaWMp IFJUUCBTdHJlYW0/DQoNCltTdFddDQpObywgUlRQIG1lZGlhIHN0cmVhbSBhbmQgUlRQIHN0cmVh bSBhcmUgbWVhbnQgdG8gYmUgdGhlIHNhbWUgaW4gYWxsIGNhc2VzLg0KSSB3ZW50IHRocm91Z2gg dGhlIGRvYyBhbmQgZml4ZWQgYXMgYXBwcm9wcmlhdGUsIHVzaW5nIKn4UlRQIHN0cmVhban3DQoo aG9wZWZ1bGx5KSBjb25zaXN0ZW50bHkuDQoNCltCb10NCiogV2hhdCBpcyBhICJDb250ZW50IHNv dXJjZSIgaW4gMy42PyBJcyBpdCBhIE1lZGlhIFNvdXJjZT8NCg0KW1N0V10NClRyaWNreS4gIElu IDMuNiwgqfhjb250ZW50IHNvdXJjZan3IGlzIHVzZWQgdG8gaWRlbnRpZnkgdGhlIE1lZGlhIHNl bmRlciBhcw0KYSB3aG9sZTogdW5jb21wcmVzc2VkIHN0cmVhbSBnZW5lcmF0aW9uICh0aHJvdWdo IG1peGluZyBvciBhY3F1aXNpdGlvbiksDQplbmNvZGluZywgcGFja2V0aXppbmcuICAgqfhFbmRw b2ludKn3IG1heSBiZSBtb3JlIGFwcHJvcHJpYXRlLiAgSG93ZXZlciwNCnRoYXQgd291bGQgaW1w bHkgdGhhdCBhIG1pZGRsZWJveCBsaWtlIGEgTWl4ZXIgb3IgTUNVIGFyZSBhbHNvIGVuZHBvaW50 cywNCndoaWNoIGlzIGNvdW50ZXItaW50dWl0aXZlLCBhdCBsZWFzdCB0byBtZS4gIEkgdHJpZWQg dG8gd29yZCBhcm91bmQuDQoNCltCb10NCiogV2hhdCBpcyBhICJDb25mZXJlbmNlIHNlc3Npb24i IGluIDMuNj8gSXMgaXQgYSBDb21tdW5pY2F0aW9uIFNlc3Npb24sDQpvciBzb21lIHNwZWNpYWxp emF0aW9uIG9mIGl0Pw0KDQpbU3RXXQ0KQ29tbXVuaWNhdGlvbiBTZXNzaW9uIHNlZW1zIHJpZ2h0 Lg0KDQpbQm9dDQoqIENhbiB5b3UgZXhwbGFpbiBhIGJpdCBvZiB3aGF0IGlzIGEgIlNlc3Npb24g cGFydGljaXBhbnQiIGluIDMuNj8gVGhlcmUNCmFyZSBkaXNjdXNzaW9ucyBvbiB0aGUgdXNlIG9m IEVuZCBQb2ludCBhbmQvb3IgUGFydGljaXBhbnQgaW4gdGF4b25vbXksDQpzbyBJJ20gaGVzaXRh bnQgdG8gc3VnZ2VzdCBhbnkgdGF4b25vbXkgdGVybSByaWdodCBub3cgc2luY2UgaXQgbWF5DQpj aGFuZ2UuDQoNCltTdFddDQpTZXNzaW9uIHBhcnRpY2lwYW50cyByZWZlcnMgdG8gUlRQIHNlbmRp bmcvcmVjZWl2aW5nIGVudGl0aWVzIHRoYXQgdGFrZQ0KcGFydCBvZiB0aGUgc2FtZSBSVFAgc2Vz c2lvbi4gIEluc29mYXIsIHRheG9ub215LTAyqfZzIEVuZCBQb2ludCB3b3VsZCBiZQ0KYXBwcm9w cmlhdGUsIHdpdGggdGhlIGFkZGl0aW9uYWwgcmVtYXJrIHRoYXQgdGhlc2UgRW5kIFBvaW50cyBz aGFyZSBvbmUNClJUUCBzZXNzaW9uLg0KDQpUaGUgd29yZCCp+HBhcnRpY2lwYW50qfcgaXMgdXNl ZCB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCBpbiBhIG51bWJlciBvZg0KZGlmZmVyZW50IGNvbnRl eHRzLCB1c3VhbGx5IGJ1dCBub3QgYWx3YXlzIHdpdGggYSBtZWFuaW5nIHNpbWlsYXIgdG8gRW5k DQpQb2ludCBpbiB0YXhvbm9teS4gIEkgaGF2ZSByZXBsYWNlZCCp+HBhcnRpY2lwYW50qfcgd2l0 aCCp+EVuZCBQb2ludKn3IHdoZXJlDQphcHByb3ByaWF0ZSwgYW5kIGxlZnQgaXQgKHVzdWFsbHkg d2l0aCBxdWFsaWZpZXJzKSBvdGhlcndpc2UuDQoNCltCb10NCiogVGhlIHN0YW5kLWFsb25lIHRl cm0gInN0cmVhbSIgaXMgdXNlZCBpbiBtYW55IHBsYWNlcyB0aHJvdWdob3V0IHRoZQ0KZG9jdW1l bnQuIEkgdGhpbmsgaXQgdmVyeSByZWFzb25hYmxlIHRvIGp1c3QgYXNzdW1lIGl0IGlzIGEgc2hv cnQgZm9yDQoiUlRQIFN0cmVhbSIsIGJ1dCB5b3UgbWF5IHdhbnQgdG8gbWFrZSBzdWNoIGNvbW1l bnQgZWFybHkgb24gaW4gdGhlDQpkb2N1bWVudC4gSSBmb3VuZCBubyBwbGFjZSBpbiB0aGUgZG9j dW1lbnQgd2hlcmUgc3VjaCBhc3N1bXB0aW9uIHdvdWxkIGJlDQppbnZhbGlkLg0KDQpbU3RXXQ0K Rml4ZWQgYnkgdXNpbmcgqfhSVFAgc3RyZWFtIGNvbnNpc3RlbnRseS4NCg0KW0JvXQ0KKiBUaGUg dGVybSAiZ2xvYmFsIHNlc3Npb24iIGlzIHVzZWQgaW4gMy42OyBJIGZpbmQgaXQgYSBiaXQgaGFy ZCB0bw0KdW5kZXJzdGFuZCB3aGF0IGlzIG1lYW50Lg0KDQpbU3RXXQ0KSSB0aGluayBpdKn2cyCp +ENvbW11bmljYXRpb24gU2Vzc2lvbqn3IChldmVyeSBFbmRwb2ludCBhbmQgZXZlcnkgbWlkZGxl IGJveA0KdGhhdCBhcmUgdGFsa2luZyB0byBlYWNoIG90aGVyKS4gIEZpeGVkLg0KDQpbQm9dDQoq IFNlY3Rpb24gMy42LjEgY291bGQgcG9zc2libHkgYmVuZWZpdCBmcm9tIHVzaW5nIHRoZSB0YXhv bm9teSB0ZXJtDQoiRW5jb2RlZCBTdHJlYW0iDQoNCltTdFddDQpDb3JyZWN0LiAgQ2xhcmlmaWVk Lg0KDQpbQm9dDQoqIE5pdDogRmlndXJlIDMgKGluIDMuMi4xLjMpIGFuZCBGaWd1cmUgNCAoaW4g My4yLjIpIGhhdmUgdGhlIHNhbWUNCmNhcHRpb247IGlzIHRoaXMgaW50ZW5kZWQ/DQoNCltTdFdd DQpOby4gIEZpeGVkLg0KDQo= From nobody Fri Aug 8 07:00:08 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0561B2A77 for ; Fri, 8 Aug 2014 07:00:07 -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 yo9r3PRC6hWo for ; Fri, 8 Aug 2014 07:00:04 -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 306741B29CD for ; Fri, 8 Aug 2014 07:00:04 -0700 (PDT) Received: from [130.209.247.112] (port=57718 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 1XFki9-0006WG-8E; Fri, 08 Aug 2014 15:00:02 +0100 Content-Type: text/plain; charset=euc-kr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Fri, 8 Aug 2014 14:59:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3147A00C-8D9D-41FD-8A4B-273972E769B0@csperkins.org> References: To: Stephan Wenger 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/avt/BDnNoCjS-Ne8Givs929IRCjF0-U Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Topologies-update, reply to Bo's review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 14:00:07 -0000 Stephan, The new text in 3.10 confuses me: why can=A1=AFt the subunits be part of = a common RTP session? You have: +---------------------+ | Endpoint A | | Local Area Network | | +------------+ | | +->| Audio |<+-RTP---\ | | +------------+ | \ +------+ | | +------------+ | +-->| | | +->| Video |<+-RTP-------->| B | | | +------------+ | +-->| | | | +------------+ | / +------+ | +->| Control |<+-SIP---/ | +------------+ | +---------------------+ If B sends reception reports so that the audio part of A can see the = SSRCs used by the video and Control parts of A, then you have a single = RTP session. I agree that a single RTP session isn=A1=AFt required here, but it = doesn=A1=AFt seem to be prohibited. Cheers, Colin On 8 Aug 2014, at 00:14, Stephan Wenger wrote: > Hi all, >=20 > You may have noticed that I just posted version -03 of the > topologies-update draft. The main changes are alignment with the > terminology used in avtext=A1=AFs grouping taxonomy draft, and a = rewrite of > section 3.10 (split-component terminal). >=20 > As per guidance received in Toronto, I did include copy-pastes of = those > few definitions of the taxonomy draft required herein, so to keep the = two > drafts independent. However, I have also asked the RFC editor to = replace > those definitions with a reference to a forthcoming taxonomy-RFC, if = such > can be done without undue delay. See section 2.2. >=20 > Section 3.10 was close to unparsable--at least very confusing--which > triggered the rewrite. I think it=A1=AFs better now, but it certainly = needs a > fresh review. >=20 > Towards the end of this email, find my responses to Bo Burman=A1=AFs = thorough > review of version -02, posted to this list on 6/11/14. I had private > communication with Bo during the editing process, and he=A1=AFs happy = with the > result and found his points addressed. >=20 > My list of open issues of this draft is now empty. WGLC would be fine > with me. Please review, comment, and get this thing out of the door. >=20 > Thanks, > Stephan >=20 > On 6/11/14, 2:39 AM, "Bo Burman" wrote: >=20 > Hi all, >=20 > [Bo] I reviewed this as a part of the ongoing update of the taxonomy = draft > to > try to align them, and have the following comments on the > topologies-update-02: > * What is meant with "Media Flow" in 3.2.1.3; is it a set of RTP = Streams? > In that case, does this set have any specific characteristics? >=20 > [StW] >=20 > The comments relates to the description of Fig. 3. No, the =A9=F8media = flow=A9=F7 > is really only a single RTP stream (without FEC) to which FEC is added = by > the translator. The relevant paragraph was poorly and overly broadly > written, and I tightened the language. >=20 > [Bo] > * (At least) in 3.2.2 and 3.3.3, the term "flow" is used in "RTP flow" = or > "packet flow"; how is that different from taxonomy RTP Stream? >=20 > [StW] > Very good catch; the language here (mostly from 5117) was really in = need > to be tightened up. I checked the various occurrences of =A9=F8flow=A9=F7= , and > replaced them with =A9=F8RTP stream=A9=F7 where appropriate. The = remaining =A9=F8flow=A9=F7s > are transport flows, which is basically the flow of packets in a = transport > association (five tuple). >=20 > [Bo] > * The terms "transport flow" or just "flow" are heavily used in 3.4; > again, as with "Media Flow", is there any specific distinction assumed = in > this besides possibly being a set of RTP Streams? >=20 > [StW] > Yes, in 3.4, transport flow refers to packets going over a 5 tuple, = see > above. I hope this is now clear from context. >=20 > [Bo] > * The term "RTP media stream" is used in many places; is there an > intended specialization compared to a (generic) RTP Stream? >=20 > [StW] > No, RTP media stream and RTP stream are meant to be the same in all = cases. > I went through the doc and fixed as appropriate, using =A9=F8RTP = stream=A9=F7 > (hopefully) consistently. >=20 > [Bo] > * What is a "Content source" in 3.6? Is it a Media Source? >=20 > [StW] > Tricky. In 3.6, =A9=F8content source=A9=F7 is used to identify the = Media sender as > a whole: uncompressed stream generation (through mixing or = acquisition), > encoding, packetizing. =A9=F8Endpoint=A9=F7 may be more appropriate. = However, > that would imply that a middlebox like a Mixer or MCU are also = endpoints, > which is counter-intuitive, at least to me. I tried to word around. >=20 > [Bo] > * What is a "Conference session" in 3.6? Is it a Communication = Session, > or some specialization of it? >=20 > [StW] > Communication Session seems right. >=20 > [Bo] > * Can you explain a bit of what is a "Session participant" in 3.6? = There > are discussions on the use of End Point and/or Participant in = taxonomy, > so I'm hesitant to suggest any taxonomy term right now since it may > change. >=20 > [StW] > Session participants refers to RTP sending/receiving entities that = take > part of the same RTP session. Insofar, taxonomy-02=A9=F6s End Point = would be > appropriate, with the additional remark that these End Points share = one > RTP session. >=20 > The word =A9=F8participant=A9=F7 is used throughout the document in a = number of > different contexts, usually but not always with a meaning similar to = End > Point in taxonomy. I have replaced =A9=F8participant=A9=F7 with =A9=F8E= nd Point=A9=F7 where > appropriate, and left it (usually with qualifiers) otherwise. >=20 > [Bo] > * The stand-alone term "stream" is used in many places throughout the > document. I think it very reasonable to just assume it is a short for > "RTP Stream", but you may want to make such comment early on in the > document. I found no place in the document where such assumption would = be > invalid. >=20 > [StW] > Fixed by using =A9=F8RTP stream consistently. >=20 > [Bo] > * The term "global session" is used in 3.6; I find it a bit hard to > understand what is meant. >=20 > [StW] > I think it=A9=F6s =A9=F8Communication Session=A9=F7 (every Endpoint = and every middle box > that are talking to each other). Fixed. >=20 > [Bo] > * Section 3.6.1 could possibly benefit from using the taxonomy term > "Encoded Stream" >=20 > [StW] > Correct. Clarified. >=20 > [Bo] > * Nit: Figure 3 (in 3.2.1.3) and Figure 4 (in 3.2.2) have the same > caption; is this intended? >=20 > [StW] > No. Fixed. >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From nobody Fri Aug 8 07:31:02 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248751B2B38 for ; Fri, 8 Aug 2014 07:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 lLjroXrD5i64 for ; Fri, 8 Aug 2014 07:30:58 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B00B1B2B23 for ; Fri, 8 Aug 2014 07:30:57 -0700 (PDT) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 8 Aug 2014 14:30:47 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.136]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.136]) with mapi id 15.00.0995.014; Fri, 8 Aug 2014 14:30:47 +0000 From: Stephan Wenger To: Colin Perkins Thread-Topic: [AVTCORE] Topologies-update, reply to Bo's review Thread-Index: AQHPspVWg15Q2HN36EeDlcGGcl3C3pvGvOWA//+TPwA= Date: Fri, 8 Aug 2014 14:30:46 +0000 Message-ID: References: <3147A00C-8D9D-41FD-8A4B-273972E769B0@csperkins.org> In-Reply-To: <3147A00C-8D9D-41FD-8A4B-273972E769B0@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(479174003)(199002)(51704005)(53754006)(164054003)(24454002)(189002)(31966008)(64706001)(99286002)(4396001)(76176999)(105586002)(95666004)(74662001)(76482001)(99396002)(36756003)(20776003)(85306004)(21056001)(106116001)(74502001)(80022001)(106356001)(110136001)(83322001)(92566001)(107046002)(15395725005)(19580395003)(77096002)(19580405001)(86362001)(15975445006)(54356999)(81542001)(66066001)(92726001)(2656002)(15202345003)(83072002)(81342001)(46102001)(79102001)(85852003)(101416001)(50986999)(87936001)(77982001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/avt/ISTljtUx6TzD78umleQVeJs-sP0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Topologies-update, reply to Bo's review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 14:31:01 -0000 SGkgQ29saW4sDQoNClRoZSB0d28gUlRQIHN1YnVuaXRzIChBdWRpbyBhbmQgVmlkZW8pIHNoYXJl IHRoZSBzYW1lIENOQU1FLCBhcyB0aGV5IGFyZQ0Kc2VtYW50aWNhbGx5IGNvdXBsZWQsIGFuZCB0 aGV5IHVzZSBkaXN0aW5jdCB0cmFuc3BvcnQgYWRkcmVzc2VzLiAgVGhlc2UNCmFyZSB0aGUgZGlz dGluZ3Vpc2hpbmcgZmVhdHVyZXMgb2YgdGhpcyB0ZXJtaW5hbKGvcyB0b3BvbG9neS4gIEluIHRo YXQNCmNhc2UsIEF1ZGlvIGFuZCBWaWRlbyB3b3VsZCBhdCBsZWFzdCB2aW9sYXRlIGEgobBTSE9V TEShsSBjbGF1c2Ugb2YgUkZDIDM1NTANCihzZWN0aW9uIDYuNS4xLCBmaXJzdCBidWxsZXQgb24g cGFnZSA0NykgaWYgdGhleSB3ZXJlIGluIHRoZSBzYW1lIFJUUA0Kc2Vzc2lvbiwgbm8/DQoNCkEg ZGlmZmVyZW50IGFkdmlzZSB3b3VsZCBiZSB0byBzYXkgdGhhdCBpZiBvbmUgZGVjb21wb3NlcyBh biBlbmRwb2ludCwgYQ0KZ29vZCBjaG9pY2Ugb2YgdGhlIENOQU1FIHdvdWxkIGJlIHNvbWV0aGlu ZyBsaWtlDQpqb2huLmRvZS5hdWRpb0B2aWRjb25mcm9vbTEuZXhhbXBsZS5jb20gYW5kDQpqb2hu LmRvZS52aWRlb0B2aWRlb2NvbmZyb29tMS5leGFtcGxlLmNvbSwgcmF0aGVyIHRoYW4gdXNpbmcN CmpvaG4uZG9lQHZpZGVvY29uZnJvb20xLmV4YW1wbGUuY29tIGFzIENOQU1FIGZvciBib3RoIEF1 ZGlvIGFuZCBWaWRlby4NClNvLCBkaXN0aW5jdCBDTkFNRXMsIGJ1dCBzdGlsbCBodW1hbi1vYnNl cnZhYmxlIHNlbWFudGljIGNvdXBsaW5nIChldmVuIGENCnJlYXNvbmFibHkgc21hcnQgbWFjaGlu ZSBjb3VsZCBmaWd1cmUgaXQgb3V0IGlmIGNvbmZpZ3VyZWQgY29ycmVjdGx5IDotKQ0KDQpTaG91 bGQgSSBhZGQgdGhpcyBhcyBhIHNlbnNpYmxlIGRlc2lnbiBhbHRlcm5hdGl2ZT8gIE9yIGFtIEkg aW4gdGhlIHdvb2RzPw0KDQpTdGVwaGFuDQoNCg0KDQoNCk9uIDgvOC8xNCwgNjo1OSBBTSwgIkNv bGluIFBlcmtpbnMiIDxjc3BAY3NwZXJraW5zLm9yZz4gd3JvdGU6DQoNCj5TdGVwaGFuLA0KPg0K PlRoZSBuZXcgdGV4dCBpbiAzLjEwIGNvbmZ1c2VzIG1lOiB3aHkgY2Fuoa90IHRoZSBzdWJ1bml0 cyBiZSBwYXJ0IG9mIGENCj5jb21tb24gUlRQIHNlc3Npb24/IFlvdSBoYXZlOg0KPg0KPiAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ICAgfCBFbmRwb2ludCBBICAgICAgICAgIHwNCj4gICB8 IExvY2FsIEFyZWEgTmV0d29yayAgfA0KPiAgIHwgICAgICArLS0tLS0tLS0tLS0tKyB8DQo+ICAg fCAgICstPnwgQXVkaW8gICAgICB8PCstUlRQLS0tXA0KPiAgIHwgICB8ICArLS0tLS0tLS0tLS0t KyB8ICAgICAgICBcICAgICstLS0tLS0rDQo+ICAgfCAgIHwgICstLS0tLS0tLS0tLS0rIHwgICAg ICAgICArLS0+fCAgICAgIHwNCj4gICB8ICAgKy0+fCBWaWRlbyAgICAgIHw8Ky1SVFAtLS0tLS0t LT58ICBCICAgfA0KPiAgIHwgICB8ICArLS0tLS0tLS0tLS0tKyB8ICAgICAgICAgKy0tPnwgICAg ICB8DQo+ICAgfCAgIHwgICstLS0tLS0tLS0tLS0rIHwgICAgICAgIC8gICAgKy0tLS0tLSsNCj4g ICB8ICAgKy0+fCBDb250cm9sICAgIHw8Ky1TSVAtLS0vDQo+ICAgfCAgICAgICstLS0tLS0tLS0t LS0rIHwNCj4gICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPg0KPklmIEIgc2VuZHMgcmVjZXB0 aW9uIHJlcG9ydHMgc28gdGhhdCB0aGUgYXVkaW8gcGFydCBvZiBBIGNhbiBzZWUgdGhlDQo+U1NS Q3MgdXNlZCBieSB0aGUgdmlkZW8gYW5kIENvbnRyb2wgcGFydHMgb2YgQSwgdGhlbiB5b3UgaGF2 ZSBhIHNpbmdsZQ0KPlJUUCBzZXNzaW9uLg0KPg0KPkkgYWdyZWUgdGhhdCBhIHNpbmdsZSBSVFAg c2Vzc2lvbiBpc26hr3QgcmVxdWlyZWQgaGVyZSwgYnV0IGl0IGRvZXNuoa90DQo+c2VlbSB0byBi ZSBwcm9oaWJpdGVkLg0KPg0KPkNoZWVycywNCj5Db2xpbg0KPg0KPg0KPg0KPg0KPk9uIDggQXVn IDIwMTQsIGF0IDAwOjE0LCBTdGVwaGFuIFdlbmdlciA8c3Rld2VAc3Rld2Uub3JnPiB3cm90ZToN Cj4+IEhpIGFsbCwNCj4+IA0KPj4gWW91IG1heSBoYXZlIG5vdGljZWQgdGhhdCBJIGp1c3QgcG9z dGVkIHZlcnNpb24gLTAzIG9mIHRoZQ0KPj4gdG9wb2xvZ2llcy11cGRhdGUgZHJhZnQuICBUaGUg bWFpbiBjaGFuZ2VzIGFyZSBhbGlnbm1lbnQgd2l0aCB0aGUNCj4+IHRlcm1pbm9sb2d5IHVzZWQg aW4gYXZ0ZXh0oa9zIGdyb3VwaW5nIHRheG9ub215IGRyYWZ0LCBhbmQgYSByZXdyaXRlIG9mDQo+ PiBzZWN0aW9uIDMuMTAgKHNwbGl0LWNvbXBvbmVudCB0ZXJtaW5hbCkuDQo+PiANCj4+IEFzIHBl ciBndWlkYW5jZSByZWNlaXZlZCBpbiBUb3JvbnRvLCBJIGRpZCBpbmNsdWRlIGNvcHktcGFzdGVz IG9mIHRob3NlDQo+PiBmZXcgZGVmaW5pdGlvbnMgb2YgdGhlIHRheG9ub215IGRyYWZ0IHJlcXVp cmVkIGhlcmVpbiwgc28gdG8ga2VlcCB0aGUNCj4+dHdvDQo+PiBkcmFmdHMgaW5kZXBlbmRlbnQu ICBIb3dldmVyLCBJIGhhdmUgYWxzbyBhc2tlZCB0aGUgUkZDIGVkaXRvciB0bw0KPj5yZXBsYWNl DQo+PiB0aG9zZSBkZWZpbml0aW9ucyB3aXRoIGEgcmVmZXJlbmNlIHRvIGEgZm9ydGhjb21pbmcg dGF4b25vbXktUkZDLCBpZg0KPj5zdWNoDQo+PiBjYW4gYmUgZG9uZSB3aXRob3V0IHVuZHVlIGRl bGF5LiAgU2VlIHNlY3Rpb24gMi4yLg0KPj4gDQo+PiBTZWN0aW9uIDMuMTAgd2FzIGNsb3NlIHRv IHVucGFyc2FibGUtLWF0IGxlYXN0IHZlcnkgY29uZnVzaW5nLS13aGljaA0KPj4gdHJpZ2dlcmVk IHRoZSByZXdyaXRlLiAgSSB0aGluayBpdKGvcyBiZXR0ZXIgbm93LCBidXQgaXQgY2VydGFpbmx5 IG5lZWRzDQo+PmENCj4+IGZyZXNoIHJldmlldy4NCj4+IA0KPj4gVG93YXJkcyB0aGUgZW5kIG9m IHRoaXMgZW1haWwsIGZpbmQgbXkgcmVzcG9uc2VzIHRvIEJvIEJ1cm1hbqGvcyB0aG9yb3VnaA0K Pj4gcmV2aWV3IG9mIHZlcnNpb24gLTAyLCBwb3N0ZWQgdG8gdGhpcyBsaXN0IG9uIDYvMTEvMTQu ICBJIGhhZCBwcml2YXRlDQo+PiBjb21tdW5pY2F0aW9uIHdpdGggQm8gZHVyaW5nIHRoZSBlZGl0 aW5nIHByb2Nlc3MsIGFuZCBoZaGvcyBoYXBweSB3aXRoDQo+PnRoZQ0KPj4gcmVzdWx0IGFuZCBm b3VuZCBoaXMgcG9pbnRzIGFkZHJlc3NlZC4NCj4+IA0KPj4gTXkgbGlzdCBvZiBvcGVuIGlzc3Vl cyBvZiB0aGlzIGRyYWZ0IGlzIG5vdyBlbXB0eS4gIFdHTEMgd291bGQgYmUgZmluZQ0KPj4gd2l0 aCBtZS4gIFBsZWFzZSByZXZpZXcsIGNvbW1lbnQsIGFuZCBnZXQgdGhpcyB0aGluZyBvdXQgb2Yg dGhlIGRvb3IuDQo+PiANCj4+IFRoYW5rcywNCj4+IFN0ZXBoYW4NCj4+IA0KPj4gT24gNi8xMS8x NCwgMjozOSBBTSwgIkJvIEJ1cm1hbiIgPGJvLmJ1cm1hbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0K Pj4gDQo+PiBIaSBhbGwsDQo+PiANCj4+IFtCb10gSSByZXZpZXdlZCB0aGlzIGFzIGEgcGFydCBv ZiB0aGUgb25nb2luZyB1cGRhdGUgb2YgdGhlIHRheG9ub215DQo+PmRyYWZ0DQo+PiB0bw0KPj4g dHJ5IHRvIGFsaWduIHRoZW0sIGFuZCBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHMgb24gdGhl DQo+PiB0b3BvbG9naWVzLXVwZGF0ZS0wMjoNCj4+ICogV2hhdCBpcyBtZWFudCB3aXRoICJNZWRp YSBGbG93IiBpbiAzLjIuMS4zOyBpcyBpdCBhIHNldCBvZiBSVFANCj4+U3RyZWFtcz8NCj4+IElu IHRoYXQgY2FzZSwgZG9lcyB0aGlzIHNldCBoYXZlIGFueSBzcGVjaWZpYyBjaGFyYWN0ZXJpc3Rp Y3M/DQo+PiANCj4+IFtTdFddDQo+PiANCj4+IFRoZSBjb21tZW50cyByZWxhdGVzIHRvIHRoZSBk ZXNjcmlwdGlvbiBvZiBGaWcuIDMuICBObywgdGhlIKn4bWVkaWEgZmxvd6n3DQo+PiBpcyByZWFs bHkgb25seSBhIHNpbmdsZSBSVFAgc3RyZWFtICh3aXRob3V0IEZFQykgdG8gd2hpY2ggRkVDIGlz IGFkZGVkDQo+PmJ5DQo+PiB0aGUgdHJhbnNsYXRvci4gIFRoZSByZWxldmFudCBwYXJhZ3JhcGgg d2FzIHBvb3JseSBhbmQgb3Zlcmx5IGJyb2FkbHkNCj4+IHdyaXR0ZW4sIGFuZCBJIHRpZ2h0ZW5l ZCB0aGUgbGFuZ3VhZ2UuDQo+PiANCj4+IFtCb10NCj4+ICogKEF0IGxlYXN0KSBpbiAzLjIuMiBh bmQgMy4zLjMsIHRoZSB0ZXJtICJmbG93IiBpcyB1c2VkIGluICJSVFAgZmxvdyINCj4+b3INCj4+ ICJwYWNrZXQgZmxvdyI7IGhvdyBpcyB0aGF0IGRpZmZlcmVudCBmcm9tIHRheG9ub215IFJUUCBT dHJlYW0/DQo+PiANCj4+IFtTdFddDQo+PiBWZXJ5IGdvb2QgY2F0Y2g7IHRoZSBsYW5ndWFnZSBo ZXJlIChtb3N0bHkgZnJvbSA1MTE3KSB3YXMgcmVhbGx5IGluIG5lZWQNCj4+IHRvIGJlIHRpZ2h0 ZW5lZCB1cC4gIEkgY2hlY2tlZCB0aGUgdmFyaW91cyBvY2N1cnJlbmNlcyBvZiCp+GZsb3ep9ywg YW5kDQo+PiByZXBsYWNlZCB0aGVtIHdpdGggqfhSVFAgc3RyZWFtqfcgd2hlcmUgYXBwcm9wcmlh dGUuICBUaGUgcmVtYWluaW5nDQo+Pqn4Zmxvd6n3cw0KPj4gYXJlIHRyYW5zcG9ydCBmbG93cywg d2hpY2ggaXMgYmFzaWNhbGx5IHRoZSBmbG93IG9mIHBhY2tldHMgaW4gYQ0KPj50cmFuc3BvcnQN Cj4+IGFzc29jaWF0aW9uIChmaXZlIHR1cGxlKS4NCj4+IA0KPj4gW0JvXQ0KPj4gKiBUaGUgdGVy bXMgInRyYW5zcG9ydCBmbG93IiBvciBqdXN0ICJmbG93IiBhcmUgaGVhdmlseSB1c2VkIGluIDMu NDsNCj4+IGFnYWluLCBhcyB3aXRoICJNZWRpYSBGbG93IiwgaXMgdGhlcmUgYW55IHNwZWNpZmlj IGRpc3RpbmN0aW9uIGFzc3VtZWQNCj4+aW4NCj4+IHRoaXMgYmVzaWRlcyBwb3NzaWJseSBiZWlu ZyBhIHNldCBvZiBSVFAgU3RyZWFtcz8NCj4+IA0KPj4gW1N0V10NCj4+IFllcywgaW4gMy40LCB0 cmFuc3BvcnQgZmxvdyByZWZlcnMgdG8gcGFja2V0cyBnb2luZyBvdmVyIGEgNSB0dXBsZSwgc2Vl DQo+PiBhYm92ZS4gIEkgaG9wZSB0aGlzIGlzIG5vdyBjbGVhciBmcm9tIGNvbnRleHQuDQo+PiAN Cj4+IFtCb10NCj4+ICogVGhlIHRlcm0gIlJUUCBtZWRpYSBzdHJlYW0iIGlzIHVzZWQgaW4gbWFu eSBwbGFjZXM7IGlzIHRoZXJlIGFuDQo+PiBpbnRlbmRlZCBzcGVjaWFsaXphdGlvbiBjb21wYXJl ZCB0byBhIChnZW5lcmljKSBSVFAgU3RyZWFtPw0KPj4gDQo+PiBbU3RXXQ0KPj4gTm8sIFJUUCBt ZWRpYSBzdHJlYW0gYW5kIFJUUCBzdHJlYW0gYXJlIG1lYW50IHRvIGJlIHRoZSBzYW1lIGluIGFs bA0KPj5jYXNlcy4NCj4+IEkgd2VudCB0aHJvdWdoIHRoZSBkb2MgYW5kIGZpeGVkIGFzIGFwcHJv cHJpYXRlLCB1c2luZyCp+FJUUCBzdHJlYW2p9w0KPj4gKGhvcGVmdWxseSkgY29uc2lzdGVudGx5 Lg0KPj4gDQo+PiBbQm9dDQo+PiAqIFdoYXQgaXMgYSAiQ29udGVudCBzb3VyY2UiIGluIDMuNj8g SXMgaXQgYSBNZWRpYSBTb3VyY2U/DQo+PiANCj4+IFtTdFddDQo+PiBUcmlja3kuICBJbiAzLjYs IKn4Y29udGVudCBzb3VyY2Wp9yBpcyB1c2VkIHRvIGlkZW50aWZ5IHRoZSBNZWRpYSBzZW5kZXIN Cj4+YXMNCj4+IGEgd2hvbGU6IHVuY29tcHJlc3NlZCBzdHJlYW0gZ2VuZXJhdGlvbiAodGhyb3Vn aCBtaXhpbmcgb3IgYWNxdWlzaXRpb24pLA0KPj4gZW5jb2RpbmcsIHBhY2tldGl6aW5nLiAgIKn4 RW5kcG9pbnSp9yBtYXkgYmUgbW9yZSBhcHByb3ByaWF0ZS4gIEhvd2V2ZXIsDQo+PiB0aGF0IHdv dWxkIGltcGx5IHRoYXQgYSBtaWRkbGVib3ggbGlrZSBhIE1peGVyIG9yIE1DVSBhcmUgYWxzbw0K Pj5lbmRwb2ludHMsDQo+PiB3aGljaCBpcyBjb3VudGVyLWludHVpdGl2ZSwgYXQgbGVhc3QgdG8g bWUuICBJIHRyaWVkIHRvIHdvcmQgYXJvdW5kLg0KPj4gDQo+PiBbQm9dDQo+PiAqIFdoYXQgaXMg YSAiQ29uZmVyZW5jZSBzZXNzaW9uIiBpbiAzLjY/IElzIGl0IGEgQ29tbXVuaWNhdGlvbiBTZXNz aW9uLA0KPj4gb3Igc29tZSBzcGVjaWFsaXphdGlvbiBvZiBpdD8NCj4+IA0KPj4gW1N0V10NCj4+ IENvbW11bmljYXRpb24gU2Vzc2lvbiBzZWVtcyByaWdodC4NCj4+IA0KPj4gW0JvXQ0KPj4gKiBD YW4geW91IGV4cGxhaW4gYSBiaXQgb2Ygd2hhdCBpcyBhICJTZXNzaW9uIHBhcnRpY2lwYW50IiBp biAzLjY/IFRoZXJlDQo+PiBhcmUgZGlzY3Vzc2lvbnMgb24gdGhlIHVzZSBvZiBFbmQgUG9pbnQg YW5kL29yIFBhcnRpY2lwYW50IGluIHRheG9ub215LA0KPj4gc28gSSdtIGhlc2l0YW50IHRvIHN1 Z2dlc3QgYW55IHRheG9ub215IHRlcm0gcmlnaHQgbm93IHNpbmNlIGl0IG1heQ0KPj4gY2hhbmdl Lg0KPj4gDQo+PiBbU3RXXQ0KPj4gU2Vzc2lvbiBwYXJ0aWNpcGFudHMgcmVmZXJzIHRvIFJUUCBz ZW5kaW5nL3JlY2VpdmluZyBlbnRpdGllcyB0aGF0IHRha2UNCj4+IHBhcnQgb2YgdGhlIHNhbWUg UlRQIHNlc3Npb24uICBJbnNvZmFyLCB0YXhvbm9teS0wMqn2cyBFbmQgUG9pbnQgd291bGQgYmUN Cj4+IGFwcHJvcHJpYXRlLCB3aXRoIHRoZSBhZGRpdGlvbmFsIHJlbWFyayB0aGF0IHRoZXNlIEVu ZCBQb2ludHMgc2hhcmUgb25lDQo+PiBSVFAgc2Vzc2lvbi4NCj4+IA0KPj4gVGhlIHdvcmQgqfhw YXJ0aWNpcGFudKn3IGlzIHVzZWQgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQgaW4gYSBudW1iZXIg b2YNCj4+IGRpZmZlcmVudCBjb250ZXh0cywgdXN1YWxseSBidXQgbm90IGFsd2F5cyB3aXRoIGEg bWVhbmluZyBzaW1pbGFyIHRvIEVuZA0KPj4gUG9pbnQgaW4gdGF4b25vbXkuICBJIGhhdmUgcmVw bGFjZWQgqfhwYXJ0aWNpcGFudKn3IHdpdGggqfhFbmQgUG9pbnSp9yB3aGVyZQ0KPj4gYXBwcm9w cmlhdGUsIGFuZCBsZWZ0IGl0ICh1c3VhbGx5IHdpdGggcXVhbGlmaWVycykgb3RoZXJ3aXNlLg0K Pj4gDQo+PiBbQm9dDQo+PiAqIFRoZSBzdGFuZC1hbG9uZSB0ZXJtICJzdHJlYW0iIGlzIHVzZWQg aW4gbWFueSBwbGFjZXMgdGhyb3VnaG91dCB0aGUNCj4+IGRvY3VtZW50LiBJIHRoaW5rIGl0IHZl cnkgcmVhc29uYWJsZSB0byBqdXN0IGFzc3VtZSBpdCBpcyBhIHNob3J0IGZvcg0KPj4gIlJUUCBT dHJlYW0iLCBidXQgeW91IG1heSB3YW50IHRvIG1ha2Ugc3VjaCBjb21tZW50IGVhcmx5IG9uIGlu IHRoZQ0KPj4gZG9jdW1lbnQuIEkgZm91bmQgbm8gcGxhY2UgaW4gdGhlIGRvY3VtZW50IHdoZXJl IHN1Y2ggYXNzdW1wdGlvbiB3b3VsZA0KPj5iZQ0KPj4gaW52YWxpZC4NCj4+IA0KPj4gW1N0V10N Cj4+IEZpeGVkIGJ5IHVzaW5nIKn4UlRQIHN0cmVhbSBjb25zaXN0ZW50bHkuDQo+PiANCj4+IFtC b10NCj4+ICogVGhlIHRlcm0gImdsb2JhbCBzZXNzaW9uIiBpcyB1c2VkIGluIDMuNjsgSSBmaW5k IGl0IGEgYml0IGhhcmQgdG8NCj4+IHVuZGVyc3RhbmQgd2hhdCBpcyBtZWFudC4NCj4+IA0KPj4g W1N0V10NCj4+IEkgdGhpbmsgaXSp9nMgqfhDb21tdW5pY2F0aW9uIFNlc3Npb26p9yAoZXZlcnkg RW5kcG9pbnQgYW5kIGV2ZXJ5IG1pZGRsZQ0KPj5ib3gNCj4+IHRoYXQgYXJlIHRhbGtpbmcgdG8g ZWFjaCBvdGhlcikuICBGaXhlZC4NCj4+IA0KPj4gW0JvXQ0KPj4gKiBTZWN0aW9uIDMuNi4xIGNv dWxkIHBvc3NpYmx5IGJlbmVmaXQgZnJvbSB1c2luZyB0aGUgdGF4b25vbXkgdGVybQ0KPj4gIkVu Y29kZWQgU3RyZWFtIg0KPj4gDQo+PiBbU3RXXQ0KPj4gQ29ycmVjdC4gIENsYXJpZmllZC4NCj4+ IA0KPj4gW0JvXQ0KPj4gKiBOaXQ6IEZpZ3VyZSAzIChpbiAzLjIuMS4zKSBhbmQgRmlndXJlIDQg KGluIDMuMi4yKSBoYXZlIHRoZSBzYW1lDQo+PiBjYXB0aW9uOyBpcyB0aGlzIGludGVuZGVkPw0K Pj4gDQo+PiBbU3RXXQ0KPj4gTm8uICBGaXhlZC4NCj4+IA0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBD b3JlIE1haW50ZW5hbmNlDQo+PiBhdnRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYXZ0DQo+DQo+DQo+DQo+LS0gDQo+Q29saW4gUGVya2lucw0KPmh0 dHA6Ly9jc3BlcmtpbnMub3JnLw0KPg0KPg0KPg0KDQo= From nobody Fri Aug 8 07:37:22 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4DD1B2C54 for ; Fri, 8 Aug 2014 07:37: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 ES153YQS5zvi for ; Fri, 8 Aug 2014 07:37:12 -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 90FDC1B2C50 for ; Fri, 8 Aug 2014 07:36:51 -0700 (PDT) Received: from [130.209.247.112] (port=57812 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 1XFlHk-0002Pj-QR; Fri, 08 Aug 2014 15:36:50 +0100 Content-Type: text/plain; charset=euc-kr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Fri, 8 Aug 2014 15:36:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <25F74D0B-5BB2-480F-B4FA-10D226843952@csperkins.org> References: <3147A00C-8D9D-41FD-8A4B-273972E769B0@csperkins.org> To: Stephan Wenger 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/avt/wGUkrnvEit2NDGL38bKVOrnCztk Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Topologies-update, reply to Bo's review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 14:37:19 -0000 Hi, They=A1=AFre logically part of the same endpoint, and use a common = clock, and this makes them semantically coupled anyway, so I think a = common CNAME and single RTP session makes sense (this is essentially the = design the old Mbone tools used to lip-sync when audio and video were = done with separate tools, using a coordination protocol).=20 Colin On 8 Aug 2014, at 15:30, Stephan Wenger wrote: > Hi Colin, >=20 > The two RTP subunits (Audio and Video) share the same CNAME, as they = are > semantically coupled, and they use distinct transport addresses. = These > are the distinguishing features of this terminal=A1=AFs topology. In = that > case, Audio and Video would at least violate a =A1=B0SHOULD=A1=B1 = clause of RFC 3550 > (section 6.5.1, first bullet on page 47) if they were in the same RTP > session, no? >=20 > A different advise would be to say that if one decomposes an endpoint, = a > good choice of the CNAME would be something like > john.doe.audio@vidconfroom1.example.com and > john.doe.video@videoconfroom1.example.com, rather than using > john.doe@videoconfroom1.example.com as CNAME for both Audio and Video. > So, distinct CNAMEs, but still human-observable semantic coupling = (even a > reasonably smart machine could figure it out if configured correctly = :-) >=20 > Should I add this as a sensible design alternative? Or am I in the = woods? >=20 > Stephan >=20 >=20 >=20 >=20 > On 8/8/14, 6:59 AM, "Colin Perkins" wrote: >=20 >> Stephan, >>=20 >> The new text in 3.10 confuses me: why can=A1=AFt the subunits be part = of a >> common RTP session? You have: >>=20 >> +---------------------+ >> | Endpoint A | >> | Local Area Network | >> | +------------+ | >> | +->| Audio |<+-RTP---\ >> | | +------------+ | \ +------+ >> | | +------------+ | +-->| | >> | +->| Video |<+-RTP-------->| B | >> | | +------------+ | +-->| | >> | | +------------+ | / +------+ >> | +->| Control |<+-SIP---/ >> | +------------+ | >> +---------------------+ >>=20 >> If B sends reception reports so that the audio part of A can see the >> SSRCs used by the video and Control parts of A, then you have a = single >> RTP session. >>=20 >> I agree that a single RTP session isn=A1=AFt required here, but it = doesn=A1=AFt >> seem to be prohibited. >>=20 >> Cheers, >> Colin >>=20 >>=20 >>=20 >>=20 >> On 8 Aug 2014, at 00:14, Stephan Wenger wrote: >>> Hi all, >>>=20 >>> You may have noticed that I just posted version -03 of the >>> topologies-update draft. The main changes are alignment with the >>> terminology used in avtext=A1=AFs grouping taxonomy draft, and a = rewrite of >>> section 3.10 (split-component terminal). >>>=20 >>> As per guidance received in Toronto, I did include copy-pastes of = those >>> few definitions of the taxonomy draft required herein, so to keep = the >>> two >>> drafts independent. However, I have also asked the RFC editor to >>> replace >>> those definitions with a reference to a forthcoming taxonomy-RFC, if >>> such >>> can be done without undue delay. See section 2.2. >>>=20 >>> Section 3.10 was close to unparsable--at least very confusing--which >>> triggered the rewrite. I think it=A1=AFs better now, but it = certainly needs >>> a >>> fresh review. >>>=20 >>> Towards the end of this email, find my responses to Bo Burman=A1=AFs = thorough >>> review of version -02, posted to this list on 6/11/14. I had = private >>> communication with Bo during the editing process, and he=A1=AFs = happy with >>> the >>> result and found his points addressed. >>>=20 >>> My list of open issues of this draft is now empty. WGLC would be = fine >>> with me. Please review, comment, and get this thing out of the = door. >>>=20 >>> Thanks, >>> Stephan >>>=20 >>> On 6/11/14, 2:39 AM, "Bo Burman" wrote: >>>=20 >>> Hi all, >>>=20 >>> [Bo] I reviewed this as a part of the ongoing update of the taxonomy >>> draft >>> to >>> try to align them, and have the following comments on the >>> topologies-update-02: >>> * What is meant with "Media Flow" in 3.2.1.3; is it a set of RTP >>> Streams? >>> In that case, does this set have any specific characteristics? >>>=20 >>> [StW] >>>=20 >>> The comments relates to the description of Fig. 3. No, the =A9=F8medi= a flow=A9=F7 >>> is really only a single RTP stream (without FEC) to which FEC is = added >>> by >>> the translator. The relevant paragraph was poorly and overly = broadly >>> written, and I tightened the language. >>>=20 >>> [Bo] >>> * (At least) in 3.2.2 and 3.3.3, the term "flow" is used in "RTP = flow" >>> or >>> "packet flow"; how is that different from taxonomy RTP Stream? >>>=20 >>> [StW] >>> Very good catch; the language here (mostly from 5117) was really in = need >>> to be tightened up. I checked the various occurrences of =A9=F8flow=A9= =F7, and >>> replaced them with =A9=F8RTP stream=A9=F7 where appropriate. The = remaining >>> =A9=F8flow=A9=F7s >>> are transport flows, which is basically the flow of packets in a >>> transport >>> association (five tuple). >>>=20 >>> [Bo] >>> * The terms "transport flow" or just "flow" are heavily used in 3.4; >>> again, as with "Media Flow", is there any specific distinction = assumed >>> in >>> this besides possibly being a set of RTP Streams? >>>=20 >>> [StW] >>> Yes, in 3.4, transport flow refers to packets going over a 5 tuple, = see >>> above. I hope this is now clear from context. >>>=20 >>> [Bo] >>> * The term "RTP media stream" is used in many places; is there an >>> intended specialization compared to a (generic) RTP Stream? >>>=20 >>> [StW] >>> No, RTP media stream and RTP stream are meant to be the same in all >>> cases. >>> I went through the doc and fixed as appropriate, using =A9=F8RTP = stream=A9=F7 >>> (hopefully) consistently. >>>=20 >>> [Bo] >>> * What is a "Content source" in 3.6? Is it a Media Source? >>>=20 >>> [StW] >>> Tricky. In 3.6, =A9=F8content source=A9=F7 is used to identify the = Media sender >>> as >>> a whole: uncompressed stream generation (through mixing or = acquisition), >>> encoding, packetizing. =A9=F8Endpoint=A9=F7 may be more = appropriate. However, >>> that would imply that a middlebox like a Mixer or MCU are also >>> endpoints, >>> which is counter-intuitive, at least to me. I tried to word around. >>>=20 >>> [Bo] >>> * What is a "Conference session" in 3.6? Is it a Communication = Session, >>> or some specialization of it? >>>=20 >>> [StW] >>> Communication Session seems right. >>>=20 >>> [Bo] >>> * Can you explain a bit of what is a "Session participant" in 3.6? = There >>> are discussions on the use of End Point and/or Participant in = taxonomy, >>> so I'm hesitant to suggest any taxonomy term right now since it may >>> change. >>>=20 >>> [StW] >>> Session participants refers to RTP sending/receiving entities that = take >>> part of the same RTP session. Insofar, taxonomy-02=A9=F6s End Point = would be >>> appropriate, with the additional remark that these End Points share = one >>> RTP session. >>>=20 >>> The word =A9=F8participant=A9=F7 is used throughout the document in = a number of >>> different contexts, usually but not always with a meaning similar to = End >>> Point in taxonomy. I have replaced =A9=F8participant=A9=F7 with = =A9=F8End Point=A9=F7 where >>> appropriate, and left it (usually with qualifiers) otherwise. >>>=20 >>> [Bo] >>> * The stand-alone term "stream" is used in many places throughout = the >>> document. I think it very reasonable to just assume it is a short = for >>> "RTP Stream", but you may want to make such comment early on in the >>> document. I found no place in the document where such assumption = would >>> be >>> invalid. >>>=20 >>> [StW] >>> Fixed by using =A9=F8RTP stream consistently. >>>=20 >>> [Bo] >>> * The term "global session" is used in 3.6; I find it a bit hard to >>> understand what is meant. >>>=20 >>> [StW] >>> I think it=A9=F6s =A9=F8Communication Session=A9=F7 (every Endpoint = and every middle >>> box >>> that are talking to each other). Fixed. >>>=20 >>> [Bo] >>> * Section 3.6.1 could possibly benefit from using the taxonomy term >>> "Encoded Stream" >>>=20 >>> [StW] >>> Correct. Clarified. >>>=20 >>> [Bo] >>> * Nit: Figure 3 (in 3.2.1.3) and Figure 4 (in 3.2.2) have the same >>> caption; is this intended? >>>=20 >>> [StW] >>> No. Fixed. >>>=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 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From nobody Fri Aug 8 07:38:10 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD481B2C41 for ; Fri, 8 Aug 2014 07:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 3Hpcg2788hzM for ; Fri, 8 Aug 2014 07:38:00 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99E01B2C4E for ; Fri, 8 Aug 2014 07:37:10 -0700 (PDT) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 8 Aug 2014 14:37:07 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.136]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.136]) with mapi id 15.00.0995.014; Fri, 8 Aug 2014 14:37:07 +0000 From: Stephan Wenger To: Stephan Wenger , Colin Perkins Thread-Topic: [AVTCORE] Topologies-update, reply to Bo's review Thread-Index: AQHPspVWg15Q2HN36EeDlcGGcl3C3pvGvOWA//+TPwCAAAG4gA== Date: Fri, 8 Aug 2014 14:37:06 +0000 Message-ID: References: <3147A00C-8D9D-41FD-8A4B-273972E769B0@csperkins.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(479174003)(199002)(51704005)(53754006)(164054003)(24454002)(189002)(31966008)(64706001)(99286002)(4396001)(76176999)(105586002)(95666004)(74662001)(76482001)(99396002)(36756003)(20776003)(85306004)(21056001)(106116001)(74502001)(80022001)(106356001)(83322001)(92566001)(107046002)(15395725005)(19580395003)(77096002)(19580405001)(86362001)(15975445006)(54356999)(81542001)(66066001)(92726001)(2656002)(15202345003)(83072002)(81342001)(46102001)(79102001)(85852003)(101416001)(50986999)(87936001)(77982001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="euc-kr" Content-ID: <30DE9F863619E94E834F8F2E00B348D8@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/avt/thBw8vzGg5N4DYyDerDY5lg8HXY Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Topologies-update, reply to Bo's review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 14:38:08 -0000 VWgsIHJlcGxhY2UgdGhlIKGwSm9obi5Eb2WhsSB3aXRoIHRoZSA5NiBiaXRzIG9mIFJGQyA3MDIy LCBwbGVhc2UuICBCdXQNCmxlYXZlIHRoZSChsC5hdWRpbyIgYW5kIKGwLnZpZGVvIg0KU3RlcGhh bg0KDQpPbiA4LzgvMTQsIDc6MzAgQU0sICJTdGVwaGFuIFdlbmdlciIgPHN0ZXdlQHN0ZXdlLm9y Zz4gd3JvdGU6DQoNCj5IaSBDb2xpbiwNCj4NCj5UaGUgdHdvIFJUUCBzdWJ1bml0cyAoQXVkaW8g YW5kIFZpZGVvKSBzaGFyZSB0aGUgc2FtZSBDTkFNRSwgYXMgdGhleSBhcmUNCj5zZW1hbnRpY2Fs bHkgY291cGxlZCwgYW5kIHRoZXkgdXNlIGRpc3RpbmN0IHRyYW5zcG9ydCBhZGRyZXNzZXMuICBU aGVzZQ0KPmFyZSB0aGUgZGlzdGluZ3Vpc2hpbmcgZmVhdHVyZXMgb2YgdGhpcyB0ZXJtaW5hbKGv cyB0b3BvbG9neS4gIEluIHRoYXQNCj5jYXNlLCBBdWRpbyBhbmQgVmlkZW8gd291bGQgYXQgbGVh c3QgdmlvbGF0ZSBhIKGwU0hPVUxEobEgY2xhdXNlIG9mIFJGQyAzNTUwDQo+KHNlY3Rpb24gNi41 LjEsIGZpcnN0IGJ1bGxldCBvbiBwYWdlIDQ3KSBpZiB0aGV5IHdlcmUgaW4gdGhlIHNhbWUgUlRQ DQo+c2Vzc2lvbiwgbm8/DQo+DQo+QSBkaWZmZXJlbnQgYWR2aXNlIHdvdWxkIGJlIHRvIHNheSB0 aGF0IGlmIG9uZSBkZWNvbXBvc2VzIGFuIGVuZHBvaW50LCBhDQo+Z29vZCBjaG9pY2Ugb2YgdGhl IENOQU1FIHdvdWxkIGJlIHNvbWV0aGluZyBsaWtlDQo+am9obi5kb2UuYXVkaW9AdmlkY29uZnJv b20xLmV4YW1wbGUuY29tIGFuZA0KPmpvaG4uZG9lLnZpZGVvQHZpZGVvY29uZnJvb20xLmV4YW1w bGUuY29tLCByYXRoZXIgdGhhbiB1c2luZw0KPmpvaG4uZG9lQHZpZGVvY29uZnJvb20xLmV4YW1w bGUuY29tIGFzIENOQU1FIGZvciBib3RoIEF1ZGlvIGFuZCBWaWRlby4NCj5TbywgZGlzdGluY3Qg Q05BTUVzLCBidXQgc3RpbGwgaHVtYW4tb2JzZXJ2YWJsZSBzZW1hbnRpYyBjb3VwbGluZyAoZXZl biBhDQo+cmVhc29uYWJseSBzbWFydCBtYWNoaW5lIGNvdWxkIGZpZ3VyZSBpdCBvdXQgaWYgY29u ZmlndXJlZCBjb3JyZWN0bHkgOi0pDQo+DQo+U2hvdWxkIEkgYWRkIHRoaXMgYXMgYSBzZW5zaWJs ZSBkZXNpZ24gYWx0ZXJuYXRpdmU/ICBPciBhbSBJIGluIHRoZSB3b29kcz8NCj4NCj5TdGVwaGFu DQo+DQo+DQo+DQo+DQo+T24gOC84LzE0LCA2OjU5IEFNLCAiQ29saW4gUGVya2lucyIgPGNzcEBj c3BlcmtpbnMub3JnPiB3cm90ZToNCj4NCj4+U3RlcGhhbiwNCj4+DQo+PlRoZSBuZXcgdGV4dCBp biAzLjEwIGNvbmZ1c2VzIG1lOiB3aHkgY2Fuoa90IHRoZSBzdWJ1bml0cyBiZSBwYXJ0IG9mIGEN Cj4+Y29tbW9uIFJUUCBzZXNzaW9uPyBZb3UgaGF2ZToNCj4+DQo+PiAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0rDQo+PiAgIHwgRW5kcG9pbnQgQSAgICAgICAgICB8DQo+PiAgIHwgTG9jYWwgQXJl YSBOZXR3b3JrICB8DQo+PiAgIHwgICAgICArLS0tLS0tLS0tLS0tKyB8DQo+PiAgIHwgICArLT58 IEF1ZGlvICAgICAgfDwrLVJUUC0tLVwNCj4+ICAgfCAgIHwgICstLS0tLS0tLS0tLS0rIHwgICAg ICAgIFwgICAgKy0tLS0tLSsNCj4+ICAgfCAgIHwgICstLS0tLS0tLS0tLS0rIHwgICAgICAgICAr LS0+fCAgICAgIHwNCj4+ICAgfCAgICstPnwgVmlkZW8gICAgICB8PCstUlRQLS0tLS0tLS0+fCAg QiAgIHwNCj4+ICAgfCAgIHwgICstLS0tLS0tLS0tLS0rIHwgICAgICAgICArLS0+fCAgICAgIHwN Cj4+ICAgfCAgIHwgICstLS0tLS0tLS0tLS0rIHwgICAgICAgIC8gICAgKy0tLS0tLSsNCj4+ICAg fCAgICstPnwgQ29udHJvbCAgICB8PCstU0lQLS0tLw0KPj4gICB8ICAgICAgKy0tLS0tLS0tLS0t LSsgfA0KPj4gICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4NCj4+SWYgQiBzZW5kcyByZWNl cHRpb24gcmVwb3J0cyBzbyB0aGF0IHRoZSBhdWRpbyBwYXJ0IG9mIEEgY2FuIHNlZSB0aGUNCj4+ U1NSQ3MgdXNlZCBieSB0aGUgdmlkZW8gYW5kIENvbnRyb2wgcGFydHMgb2YgQSwgdGhlbiB5b3Ug aGF2ZSBhIHNpbmdsZQ0KPj5SVFAgc2Vzc2lvbi4NCj4+DQo+PkkgYWdyZWUgdGhhdCBhIHNpbmds ZSBSVFAgc2Vzc2lvbiBpc26hr3QgcmVxdWlyZWQgaGVyZSwgYnV0IGl0IGRvZXNuoa90DQo+PnNl ZW0gdG8gYmUgcHJvaGliaXRlZC4NCj4+DQo+PkNoZWVycywNCj4+Q29saW4NCj4+DQo+Pg0KPj4N Cj4+DQo+Pk9uIDggQXVnIDIwMTQsIGF0IDAwOjE0LCBTdGVwaGFuIFdlbmdlciA8c3Rld2VAc3Rl d2Uub3JnPiB3cm90ZToNCj4+PiBIaSBhbGwsDQo+Pj4gDQo+Pj4gWW91IG1heSBoYXZlIG5vdGlj ZWQgdGhhdCBJIGp1c3QgcG9zdGVkIHZlcnNpb24gLTAzIG9mIHRoZQ0KPj4+IHRvcG9sb2dpZXMt dXBkYXRlIGRyYWZ0LiAgVGhlIG1haW4gY2hhbmdlcyBhcmUgYWxpZ25tZW50IHdpdGggdGhlDQo+ Pj4gdGVybWlub2xvZ3kgdXNlZCBpbiBhdnRleHShr3MgZ3JvdXBpbmcgdGF4b25vbXkgZHJhZnQs IGFuZCBhIHJld3JpdGUgb2YNCj4+PiBzZWN0aW9uIDMuMTAgKHNwbGl0LWNvbXBvbmVudCB0ZXJt aW5hbCkuDQo+Pj4gDQo+Pj4gQXMgcGVyIGd1aWRhbmNlIHJlY2VpdmVkIGluIFRvcm9udG8sIEkg ZGlkIGluY2x1ZGUgY29weS1wYXN0ZXMgb2YgdGhvc2UNCj4+PiBmZXcgZGVmaW5pdGlvbnMgb2Yg dGhlIHRheG9ub215IGRyYWZ0IHJlcXVpcmVkIGhlcmVpbiwgc28gdG8ga2VlcCB0aGUNCj4+PnR3 bw0KPj4+IGRyYWZ0cyBpbmRlcGVuZGVudC4gIEhvd2V2ZXIsIEkgaGF2ZSBhbHNvIGFza2VkIHRo ZSBSRkMgZWRpdG9yIHRvDQo+Pj5yZXBsYWNlDQo+Pj4gdGhvc2UgZGVmaW5pdGlvbnMgd2l0aCBh IHJlZmVyZW5jZSB0byBhIGZvcnRoY29taW5nIHRheG9ub215LVJGQywgaWYNCj4+PnN1Y2gNCj4+ PiBjYW4gYmUgZG9uZSB3aXRob3V0IHVuZHVlIGRlbGF5LiAgU2VlIHNlY3Rpb24gMi4yLg0KPj4+ IA0KPj4+IFNlY3Rpb24gMy4xMCB3YXMgY2xvc2UgdG8gdW5wYXJzYWJsZS0tYXQgbGVhc3QgdmVy eSBjb25mdXNpbmctLXdoaWNoDQo+Pj4gdHJpZ2dlcmVkIHRoZSByZXdyaXRlLiAgSSB0aGluayBp dKGvcyBiZXR0ZXIgbm93LCBidXQgaXQgY2VydGFpbmx5IG5lZWRzDQo+Pj5hDQo+Pj4gZnJlc2gg cmV2aWV3Lg0KPj4+IA0KPj4+IFRvd2FyZHMgdGhlIGVuZCBvZiB0aGlzIGVtYWlsLCBmaW5kIG15 IHJlc3BvbnNlcyB0byBCbyBCdXJtYW6hr3MNCj4+PnRob3JvdWdoDQo+Pj4gcmV2aWV3IG9mIHZl cnNpb24gLTAyLCBwb3N0ZWQgdG8gdGhpcyBsaXN0IG9uIDYvMTEvMTQuICBJIGhhZCBwcml2YXRl DQo+Pj4gY29tbXVuaWNhdGlvbiB3aXRoIEJvIGR1cmluZyB0aGUgZWRpdGluZyBwcm9jZXNzLCBh bmQgaGWhr3MgaGFwcHkgd2l0aA0KPj4+dGhlDQo+Pj4gcmVzdWx0IGFuZCBmb3VuZCBoaXMgcG9p bnRzIGFkZHJlc3NlZC4NCj4+PiANCj4+PiBNeSBsaXN0IG9mIG9wZW4gaXNzdWVzIG9mIHRoaXMg ZHJhZnQgaXMgbm93IGVtcHR5LiAgV0dMQyB3b3VsZCBiZSBmaW5lDQo+Pj4gd2l0aCBtZS4gIFBs ZWFzZSByZXZpZXcsIGNvbW1lbnQsIGFuZCBnZXQgdGhpcyB0aGluZyBvdXQgb2YgdGhlIGRvb3Iu DQo+Pj4gDQo+Pj4gVGhhbmtzLA0KPj4+IFN0ZXBoYW4NCj4+PiANCj4+PiBPbiA2LzExLzE0LCAy OjM5IEFNLCAiQm8gQnVybWFuIiA8Ym8uYnVybWFuQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4g DQo+Pj4gSGkgYWxsLA0KPj4+IA0KPj4+IFtCb10gSSByZXZpZXdlZCB0aGlzIGFzIGEgcGFydCBv ZiB0aGUgb25nb2luZyB1cGRhdGUgb2YgdGhlIHRheG9ub215DQo+Pj5kcmFmdA0KPj4+IHRvDQo+ Pj4gdHJ5IHRvIGFsaWduIHRoZW0sIGFuZCBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHMgb24g dGhlDQo+Pj4gdG9wb2xvZ2llcy11cGRhdGUtMDI6DQo+Pj4gKiBXaGF0IGlzIG1lYW50IHdpdGgg Ik1lZGlhIEZsb3ciIGluIDMuMi4xLjM7IGlzIGl0IGEgc2V0IG9mIFJUUA0KPj4+U3RyZWFtcz8N Cj4+PiBJbiB0aGF0IGNhc2UsIGRvZXMgdGhpcyBzZXQgaGF2ZSBhbnkgc3BlY2lmaWMgY2hhcmFj dGVyaXN0aWNzPw0KPj4+IA0KPj4+IFtTdFddDQo+Pj4gDQo+Pj4gVGhlIGNvbW1lbnRzIHJlbGF0 ZXMgdG8gdGhlIGRlc2NyaXB0aW9uIG9mIEZpZy4gMy4gIE5vLCB0aGUgqfhtZWRpYQ0KPj4+Zmxv d6n3DQo+Pj4gaXMgcmVhbGx5IG9ubHkgYSBzaW5nbGUgUlRQIHN0cmVhbSAod2l0aG91dCBGRUMp IHRvIHdoaWNoIEZFQyBpcyBhZGRlZA0KPj4+YnkNCj4+PiB0aGUgdHJhbnNsYXRvci4gIFRoZSBy ZWxldmFudCBwYXJhZ3JhcGggd2FzIHBvb3JseSBhbmQgb3Zlcmx5IGJyb2FkbHkNCj4+PiB3cml0 dGVuLCBhbmQgSSB0aWdodGVuZWQgdGhlIGxhbmd1YWdlLg0KPj4+IA0KPj4+IFtCb10NCj4+PiAq IChBdCBsZWFzdCkgaW4gMy4yLjIgYW5kIDMuMy4zLCB0aGUgdGVybSAiZmxvdyIgaXMgdXNlZCBp biAiUlRQIGZsb3ciDQo+Pj5vcg0KPj4+ICJwYWNrZXQgZmxvdyI7IGhvdyBpcyB0aGF0IGRpZmZl cmVudCBmcm9tIHRheG9ub215IFJUUCBTdHJlYW0/DQo+Pj4gDQo+Pj4gW1N0V10NCj4+PiBWZXJ5 IGdvb2QgY2F0Y2g7IHRoZSBsYW5ndWFnZSBoZXJlIChtb3N0bHkgZnJvbSA1MTE3KSB3YXMgcmVh bGx5IGluDQo+Pj5uZWVkDQo+Pj4gdG8gYmUgdGlnaHRlbmVkIHVwLiAgSSBjaGVja2VkIHRoZSB2 YXJpb3VzIG9jY3VycmVuY2VzIG9mIKn4Zmxvd6n3LCBhbmQNCj4+PiByZXBsYWNlZCB0aGVtIHdp dGggqfhSVFAgc3RyZWFtqfcgd2hlcmUgYXBwcm9wcmlhdGUuICBUaGUgcmVtYWluaW5nDQo+Pj6p +GZsb3ep93MNCj4+PiBhcmUgdHJhbnNwb3J0IGZsb3dzLCB3aGljaCBpcyBiYXNpY2FsbHkgdGhl IGZsb3cgb2YgcGFja2V0cyBpbiBhDQo+Pj50cmFuc3BvcnQNCj4+PiBhc3NvY2lhdGlvbiAoZml2 ZSB0dXBsZSkuDQo+Pj4gDQo+Pj4gW0JvXQ0KPj4+ICogVGhlIHRlcm1zICJ0cmFuc3BvcnQgZmxv dyIgb3IganVzdCAiZmxvdyIgYXJlIGhlYXZpbHkgdXNlZCBpbiAzLjQ7DQo+Pj4gYWdhaW4sIGFz IHdpdGggIk1lZGlhIEZsb3ciLCBpcyB0aGVyZSBhbnkgc3BlY2lmaWMgZGlzdGluY3Rpb24gYXNz dW1lZA0KPj4+aW4NCj4+PiB0aGlzIGJlc2lkZXMgcG9zc2libHkgYmVpbmcgYSBzZXQgb2YgUlRQ IFN0cmVhbXM/DQo+Pj4gDQo+Pj4gW1N0V10NCj4+PiBZZXMsIGluIDMuNCwgdHJhbnNwb3J0IGZs b3cgcmVmZXJzIHRvIHBhY2tldHMgZ29pbmcgb3ZlciBhIDUgdHVwbGUsIHNlZQ0KPj4+IGFib3Zl LiAgSSBob3BlIHRoaXMgaXMgbm93IGNsZWFyIGZyb20gY29udGV4dC4NCj4+PiANCj4+PiBbQm9d DQo+Pj4gKiBUaGUgdGVybSAiUlRQIG1lZGlhIHN0cmVhbSIgaXMgdXNlZCBpbiBtYW55IHBsYWNl czsgaXMgdGhlcmUgYW4NCj4+PiBpbnRlbmRlZCBzcGVjaWFsaXphdGlvbiBjb21wYXJlZCB0byBh IChnZW5lcmljKSBSVFAgU3RyZWFtPw0KPj4+IA0KPj4+IFtTdFddDQo+Pj4gTm8sIFJUUCBtZWRp YSBzdHJlYW0gYW5kIFJUUCBzdHJlYW0gYXJlIG1lYW50IHRvIGJlIHRoZSBzYW1lIGluIGFsbA0K Pj4+Y2FzZXMuDQo+Pj4gSSB3ZW50IHRocm91Z2ggdGhlIGRvYyBhbmQgZml4ZWQgYXMgYXBwcm9w cmlhdGUsIHVzaW5nIKn4UlRQIHN0cmVhban3DQo+Pj4gKGhvcGVmdWxseSkgY29uc2lzdGVudGx5 Lg0KPj4+IA0KPj4+IFtCb10NCj4+PiAqIFdoYXQgaXMgYSAiQ29udGVudCBzb3VyY2UiIGluIDMu Nj8gSXMgaXQgYSBNZWRpYSBTb3VyY2U/DQo+Pj4gDQo+Pj4gW1N0V10NCj4+PiBUcmlja3kuICBJ biAzLjYsIKn4Y29udGVudCBzb3VyY2Wp9yBpcyB1c2VkIHRvIGlkZW50aWZ5IHRoZSBNZWRpYSBz ZW5kZXINCj4+PmFzDQo+Pj4gYSB3aG9sZTogdW5jb21wcmVzc2VkIHN0cmVhbSBnZW5lcmF0aW9u ICh0aHJvdWdoIG1peGluZyBvcg0KPj4+YWNxdWlzaXRpb24pLA0KPj4+IGVuY29kaW5nLCBwYWNr ZXRpemluZy4gICCp+EVuZHBvaW50qfcgbWF5IGJlIG1vcmUgYXBwcm9wcmlhdGUuICBIb3dldmVy LA0KPj4+IHRoYXQgd291bGQgaW1wbHkgdGhhdCBhIG1pZGRsZWJveCBsaWtlIGEgTWl4ZXIgb3Ig TUNVIGFyZSBhbHNvDQo+Pj5lbmRwb2ludHMsDQo+Pj4gd2hpY2ggaXMgY291bnRlci1pbnR1aXRp dmUsIGF0IGxlYXN0IHRvIG1lLiAgSSB0cmllZCB0byB3b3JkIGFyb3VuZC4NCj4+PiANCj4+PiBb Qm9dDQo+Pj4gKiBXaGF0IGlzIGEgIkNvbmZlcmVuY2Ugc2Vzc2lvbiIgaW4gMy42PyBJcyBpdCBh IENvbW11bmljYXRpb24gU2Vzc2lvbiwNCj4+PiBvciBzb21lIHNwZWNpYWxpemF0aW9uIG9mIGl0 Pw0KPj4+IA0KPj4+IFtTdFddDQo+Pj4gQ29tbXVuaWNhdGlvbiBTZXNzaW9uIHNlZW1zIHJpZ2h0 Lg0KPj4+IA0KPj4+IFtCb10NCj4+PiAqIENhbiB5b3UgZXhwbGFpbiBhIGJpdCBvZiB3aGF0IGlz IGEgIlNlc3Npb24gcGFydGljaXBhbnQiIGluIDMuNj8NCj4+PlRoZXJlDQo+Pj4gYXJlIGRpc2N1 c3Npb25zIG9uIHRoZSB1c2Ugb2YgRW5kIFBvaW50IGFuZC9vciBQYXJ0aWNpcGFudCBpbiB0YXhv bm9teSwNCj4+PiBzbyBJJ20gaGVzaXRhbnQgdG8gc3VnZ2VzdCBhbnkgdGF4b25vbXkgdGVybSBy aWdodCBub3cgc2luY2UgaXQgbWF5DQo+Pj4gY2hhbmdlLg0KPj4+IA0KPj4+IFtTdFddDQo+Pj4g U2Vzc2lvbiBwYXJ0aWNpcGFudHMgcmVmZXJzIHRvIFJUUCBzZW5kaW5nL3JlY2VpdmluZyBlbnRp dGllcyB0aGF0IHRha2UNCj4+PiBwYXJ0IG9mIHRoZSBzYW1lIFJUUCBzZXNzaW9uLiAgSW5zb2Zh ciwgdGF4b25vbXktMDKp9nMgRW5kIFBvaW50IHdvdWxkDQo+Pj5iZQ0KPj4+IGFwcHJvcHJpYXRl LCB3aXRoIHRoZSBhZGRpdGlvbmFsIHJlbWFyayB0aGF0IHRoZXNlIEVuZCBQb2ludHMgc2hhcmUg b25lDQo+Pj4gUlRQIHNlc3Npb24uDQo+Pj4gDQo+Pj4gVGhlIHdvcmQgqfhwYXJ0aWNpcGFudKn3 IGlzIHVzZWQgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQgaW4gYSBudW1iZXIgb2YNCj4+PiBkaWZm ZXJlbnQgY29udGV4dHMsIHVzdWFsbHkgYnV0IG5vdCBhbHdheXMgd2l0aCBhIG1lYW5pbmcgc2lt aWxhciB0bw0KPj4+RW5kDQo+Pj4gUG9pbnQgaW4gdGF4b25vbXkuICBJIGhhdmUgcmVwbGFjZWQg qfhwYXJ0aWNpcGFudKn3IHdpdGggqfhFbmQgUG9pbnSp9w0KPj4+d2hlcmUNCj4+PiBhcHByb3By aWF0ZSwgYW5kIGxlZnQgaXQgKHVzdWFsbHkgd2l0aCBxdWFsaWZpZXJzKSBvdGhlcndpc2UuDQo+ Pj4gDQo+Pj4gW0JvXQ0KPj4+ICogVGhlIHN0YW5kLWFsb25lIHRlcm0gInN0cmVhbSIgaXMgdXNl ZCBpbiBtYW55IHBsYWNlcyB0aHJvdWdob3V0IHRoZQ0KPj4+IGRvY3VtZW50LiBJIHRoaW5rIGl0 IHZlcnkgcmVhc29uYWJsZSB0byBqdXN0IGFzc3VtZSBpdCBpcyBhIHNob3J0IGZvcg0KPj4+ICJS VFAgU3RyZWFtIiwgYnV0IHlvdSBtYXkgd2FudCB0byBtYWtlIHN1Y2ggY29tbWVudCBlYXJseSBv biBpbiB0aGUNCj4+PiBkb2N1bWVudC4gSSBmb3VuZCBubyBwbGFjZSBpbiB0aGUgZG9jdW1lbnQg d2hlcmUgc3VjaCBhc3N1bXB0aW9uIHdvdWxkDQo+Pj5iZQ0KPj4+IGludmFsaWQuDQo+Pj4gDQo+ Pj4gW1N0V10NCj4+PiBGaXhlZCBieSB1c2luZyCp+FJUUCBzdHJlYW0gY29uc2lzdGVudGx5Lg0K Pj4+IA0KPj4+IFtCb10NCj4+PiAqIFRoZSB0ZXJtICJnbG9iYWwgc2Vzc2lvbiIgaXMgdXNlZCBp biAzLjY7IEkgZmluZCBpdCBhIGJpdCBoYXJkIHRvDQo+Pj4gdW5kZXJzdGFuZCB3aGF0IGlzIG1l YW50Lg0KPj4+IA0KPj4+IFtTdFddDQo+Pj4gSSB0aGluayBpdKn2cyCp+ENvbW11bmljYXRpb24g U2Vzc2lvbqn3IChldmVyeSBFbmRwb2ludCBhbmQgZXZlcnkgbWlkZGxlDQo+Pj5ib3gNCj4+PiB0 aGF0IGFyZSB0YWxraW5nIHRvIGVhY2ggb3RoZXIpLiAgRml4ZWQuDQo+Pj4gDQo+Pj4gW0JvXQ0K Pj4+ICogU2VjdGlvbiAzLjYuMSBjb3VsZCBwb3NzaWJseSBiZW5lZml0IGZyb20gdXNpbmcgdGhl IHRheG9ub215IHRlcm0NCj4+PiAiRW5jb2RlZCBTdHJlYW0iDQo+Pj4gDQo+Pj4gW1N0V10NCj4+ PiBDb3JyZWN0LiAgQ2xhcmlmaWVkLg0KPj4+IA0KPj4+IFtCb10NCj4+PiAqIE5pdDogRmlndXJl IDMgKGluIDMuMi4xLjMpIGFuZCBGaWd1cmUgNCAoaW4gMy4yLjIpIGhhdmUgdGhlIHNhbWUNCj4+ PiBjYXB0aW9uOyBpcyB0aGlzIGludGVuZGVkPw0KPj4+IA0KPj4+IFtTdFddDQo+Pj4gTm8uICBG aXhlZC4NCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQo+Pj4g YXZ0QGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h dnQNCj4+DQo+Pg0KPj4NCj4+LS0gDQo+PkNvbGluIFBlcmtpbnMNCj4+aHR0cDovL2NzcGVya2lu cy5vcmcvDQo+Pg0KPj4NCj4+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5BdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0K PmF2dEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0 DQoNCg== From nobody Fri Aug 8 08:20:37 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8141B1B28AF for ; Fri, 8 Aug 2014 08:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 zcnm5aQEbaCz for ; Fri, 8 Aug 2014 08:20:26 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD711A04AE for ; Fri, 8 Aug 2014 08:20:26 -0700 (PDT) Received: from CO1PR07MB362.namprd07.prod.outlook.com (10.141.75.21) by CO1PR07MB125.namprd07.prod.outlook.com (10.242.167.14) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 8 Aug 2014 15:20:23 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB362.namprd07.prod.outlook.com (10.141.75.21) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 8 Aug 2014 15:20:21 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.136]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.136]) with mapi id 15.00.0995.014; Fri, 8 Aug 2014 15:20:21 +0000 From: Stephan Wenger To: Colin Perkins Thread-Topic: [AVTCORE] Topologies-update, reply to Bo's review Thread-Index: AQHPspVWg15Q2HN36EeDlcGGcl3C3pvGvOWA//+TPwCAAHcNAP//lsSA Date: Fri, 8 Aug 2014 15:20:20 +0000 Message-ID: References: <3147A00C-8D9D-41FD-8A4B-273972E769B0@csperkins.org> <25F74D0B-5BB2-480F-B4FA-10D226843952@csperkins.org> In-Reply-To: <25F74D0B-5BB2-480F-B4FA-10D226843952@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(164054003)(53754006)(24454002)(189002)(51704005)(479174003)(377454003)(199002)(50986999)(76176999)(36756003)(92566001)(106356001)(110136001)(83322001)(76482001)(77982001)(54356999)(80022001)(74502001)(83072002)(85852003)(19580405001)(19580395003)(99286002)(4396001)(31966008)(95666004)(85306004)(105586002)(74662001)(106116001)(93886004)(15202345003)(101416001)(77096002)(20776003)(46102001)(15395725005)(92726001)(107046002)(86362001)(64706001)(21056001)(87936001)(81542001)(2656002)(66066001)(15975445006)(81342001)(79102001)(99396002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB362; H:CO1PR07MB363.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/avt/DXoU6at1TIRj80HEze1fGNxdCcg Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Topologies-update, reply to Bo's review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 15:20:32 -0000 SGkgQ29saW4sDQoNCk9uIDgvOC8xNCwgNzozNiBBTSwgIkNvbGluIFBlcmtpbnMiIDxjc3BAY3Nw ZXJraW5zLm9yZz4gd3JvdGU6DQoNCj5IaSwNCj4NCj5UaGV5oa9yZSBsb2dpY2FsbHkgcGFydCBv ZiB0aGUgc2FtZSBlbmRwb2ludCwgYW5kIHVzZSBhIGNvbW1vbiBjbG9jaywgYW5kDQo+dGhpcyBt YWtlcyB0aGVtIHNlbWFudGljYWxseSBjb3VwbGVkIGFueXdheSwgc28gSSB0aGluayBhIGNvbW1v biBDTkFNRQ0KPmFuZCBzaW5nbGUgUlRQIHNlc3Npb24gbWFrZXMgc2Vuc2UgKHRoaXMgaXMgZXNz ZW50aWFsbHkgdGhlIGRlc2lnbiB0aGUNCj5vbGQgTWJvbmUgdG9vbHMgdXNlZCB0byBsaXAtc3lu YyB3aGVuIGF1ZGlvIGFuZCB2aWRlbyB3ZXJlIGRvbmUgd2l0aA0KPnNlcGFyYXRlIHRvb2xzLCB1 c2luZyBhIGNvb3JkaW5hdGlvbiBwcm90b2NvbCkuDQoNClNvIGxldKGvcyBhc3N1bWUgYSBjb21t b24gQ05BTUUsIGJ1dCBhbHNvIHNlcGFyYXRlIHRyYW5zcG9ydCBhZGRyZXNzZXMgcGVyDQpzdWJ1 bml0LiAgQm90aCB2ZXJzaW9uIDAyIGFuZCAwMyBvZiB0aGUgZHJhZnQgY29tbWVudCBvbiB0aGF0 IHNjZW5hcmlvIGFzDQpmb2xsb3dzOg0KDQqhsEl0IGlzIG5vdCByZWFsbHkgZmVhc2libGUgdG8g ZGVjb21wb3NlIG9uZSBsb2dpY2FsIGVuZC1wb2ludCBpbnRvIHR3bw0KZGlmZmVyZW50IHRyYW5z cG9ydCBub2RlcyBpbiBvbmUgUlRQIHNlc3Npb24uICBBIHRoaXJkIHBhcnR5IG1vbml0b3Igd291 bGQNCnJlcG9ydCBzdWNoIGFuIGF0dGVtcHQgYXMgdHdvIGVudGl0aWVzIGJlaW5nIHR3byBkaWZm ZXJlbnQgZW5kLXBvaW50cyB3aXRoDQphIENOQU1FIGNvbGxpc2lvbi4gIEFzIGEgcmVzdWx0LCBh IGZ1bGx5IFJUUCBjb25mb3JtYW50IGRlLWNvbXBvc2l0ZWQNCmVuZHBvaW50IGlzIG9uZSB3aGVy ZSB0aGUgZGlmZmVyZW50IGRlY29tcG9zZWQgcGFydHMgdXNlIHNlcGFyYXRlIFJUUA0Kc2Vzc2lv bnMgdG8gc2VuZCBhbmQvb3IgcmVjZWl2ZSBtZWRpYSBzdHJlYW1zIGludGVuZGVkIGZvciB0aGVt LiINCg0KWW91IHNlZW0gdG8gYXNzZXJ0IHRoYXQgdGhpcyBpcyBhIG5vbi1pc3N1ZS4gIFdoeT8N Cg0KU3RlcGhhbg0KDQoNCj4gDQo+DQo+Q29saW4NCj4NCj4NCj5PbiA4IEF1ZyAyMDE0LCBhdCAx NTozMCwgU3RlcGhhbiBXZW5nZXIgPHN0ZXdlQHN0ZXdlLm9yZz4gd3JvdGU6DQo+DQo+PiBIaSBD b2xpbiwNCj4+IA0KPj4gVGhlIHR3byBSVFAgc3VidW5pdHMgKEF1ZGlvIGFuZCBWaWRlbykgc2hh cmUgdGhlIHNhbWUgQ05BTUUsIGFzIHRoZXkgYXJlDQo+PiBzZW1hbnRpY2FsbHkgY291cGxlZCwg YW5kIHRoZXkgdXNlIGRpc3RpbmN0IHRyYW5zcG9ydCBhZGRyZXNzZXMuICBUaGVzZQ0KPj4gYXJl IHRoZSBkaXN0aW5ndWlzaGluZyBmZWF0dXJlcyBvZiB0aGlzIHRlcm1pbmFsoa9zIHRvcG9sb2d5 LiAgSW4gdGhhdA0KPj4gY2FzZSwgQXVkaW8gYW5kIFZpZGVvIHdvdWxkIGF0IGxlYXN0IHZpb2xh dGUgYSChsFNIT1VMRKGxIGNsYXVzZSBvZiBSRkMNCj4+MzU1MA0KPj4gKHNlY3Rpb24gNi41LjEs IGZpcnN0IGJ1bGxldCBvbiBwYWdlIDQ3KSBpZiB0aGV5IHdlcmUgaW4gdGhlIHNhbWUgUlRQDQo+ PiBzZXNzaW9uLCBubz8NCj4+IA0KPj4gQSBkaWZmZXJlbnQgYWR2aXNlIHdvdWxkIGJlIHRvIHNh eSB0aGF0IGlmIG9uZSBkZWNvbXBvc2VzIGFuIGVuZHBvaW50LCBhDQo+PiBnb29kIGNob2ljZSBv ZiB0aGUgQ05BTUUgd291bGQgYmUgc29tZXRoaW5nIGxpa2UNCj4+IGpvaG4uZG9lLmF1ZGlvQHZp ZGNvbmZyb29tMS5leGFtcGxlLmNvbSBhbmQNCj4+IGpvaG4uZG9lLnZpZGVvQHZpZGVvY29uZnJv b20xLmV4YW1wbGUuY29tLCByYXRoZXIgdGhhbiB1c2luZw0KPj4gam9obi5kb2VAdmlkZW9jb25m cm9vbTEuZXhhbXBsZS5jb20gYXMgQ05BTUUgZm9yIGJvdGggQXVkaW8gYW5kIFZpZGVvLg0KPj4g U28sIGRpc3RpbmN0IENOQU1FcywgYnV0IHN0aWxsIGh1bWFuLW9ic2VydmFibGUgc2VtYW50aWMg Y291cGxpbmcgKGV2ZW4NCj4+YQ0KPj4gcmVhc29uYWJseSBzbWFydCBtYWNoaW5lIGNvdWxkIGZp Z3VyZSBpdCBvdXQgaWYgY29uZmlndXJlZCBjb3JyZWN0bHkgOi0pDQo+PiANCj4+IFNob3VsZCBJ IGFkZCB0aGlzIGFzIGEgc2Vuc2libGUgZGVzaWduIGFsdGVybmF0aXZlPyAgT3IgYW0gSSBpbiB0 aGUNCj4+d29vZHM/DQo+PiANCj4+IFN0ZXBoYW4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gT24g OC84LzE0LCA2OjU5IEFNLCAiQ29saW4gUGVya2lucyIgPGNzcEBjc3BlcmtpbnMub3JnPiB3cm90 ZToNCj4+IA0KPj4+IFN0ZXBoYW4sDQo+Pj4gDQo+Pj4gVGhlIG5ldyB0ZXh0IGluIDMuMTAgY29u ZnVzZXMgbWU6IHdoeSBjYW6hr3QgdGhlIHN1YnVuaXRzIGJlIHBhcnQgb2YgYQ0KPj4+IGNvbW1v biBSVFAgc2Vzc2lvbj8gWW91IGhhdmU6DQo+Pj4gDQo+Pj4gICstLS0tLS0tLS0tLS0tLS0tLS0t LS0rDQo+Pj4gIHwgRW5kcG9pbnQgQSAgICAgICAgICB8DQo+Pj4gIHwgTG9jYWwgQXJlYSBOZXR3 b3JrICB8DQo+Pj4gIHwgICAgICArLS0tLS0tLS0tLS0tKyB8DQo+Pj4gIHwgICArLT58IEF1ZGlv ICAgICAgfDwrLVJUUC0tLVwNCj4+PiAgfCAgIHwgICstLS0tLS0tLS0tLS0rIHwgICAgICAgIFwg ICAgKy0tLS0tLSsNCj4+PiAgfCAgIHwgICstLS0tLS0tLS0tLS0rIHwgICAgICAgICArLS0+fCAg ICAgIHwNCj4+PiAgfCAgICstPnwgVmlkZW8gICAgICB8PCstUlRQLS0tLS0tLS0+fCAgQiAgIHwN Cj4+PiAgfCAgIHwgICstLS0tLS0tLS0tLS0rIHwgICAgICAgICArLS0+fCAgICAgIHwNCj4+PiAg fCAgIHwgICstLS0tLS0tLS0tLS0rIHwgICAgICAgIC8gICAgKy0tLS0tLSsNCj4+PiAgfCAgICst PnwgQ29udHJvbCAgICB8PCstU0lQLS0tLw0KPj4+ICB8ICAgICAgKy0tLS0tLS0tLS0tLSsgfA0K Pj4+ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+IA0KPj4+IElmIEIgc2VuZHMgcmVjZXB0 aW9uIHJlcG9ydHMgc28gdGhhdCB0aGUgYXVkaW8gcGFydCBvZiBBIGNhbiBzZWUgdGhlDQo+Pj4g U1NSQ3MgdXNlZCBieSB0aGUgdmlkZW8gYW5kIENvbnRyb2wgcGFydHMgb2YgQSwgdGhlbiB5b3Ug aGF2ZSBhIHNpbmdsZQ0KPj4+IFJUUCBzZXNzaW9uLg0KPj4+IA0KPj4+IEkgYWdyZWUgdGhhdCBh IHNpbmdsZSBSVFAgc2Vzc2lvbiBpc26hr3QgcmVxdWlyZWQgaGVyZSwgYnV0IGl0IGRvZXNuoa90 DQo+Pj4gc2VlbSB0byBiZSBwcm9oaWJpdGVkLg0KPj4+IA0KPj4+IENoZWVycywNCj4+PiBDb2xp bg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IE9uIDggQXVnIDIwMTQsIGF0IDAwOjE0LCBT dGVwaGFuIFdlbmdlciA8c3Rld2VAc3Rld2Uub3JnPiB3cm90ZToNCj4+Pj4gSGkgYWxsLA0KPj4+ PiANCj4+Pj4gWW91IG1heSBoYXZlIG5vdGljZWQgdGhhdCBJIGp1c3QgcG9zdGVkIHZlcnNpb24g LTAzIG9mIHRoZQ0KPj4+PiB0b3BvbG9naWVzLXVwZGF0ZSBkcmFmdC4gIFRoZSBtYWluIGNoYW5n ZXMgYXJlIGFsaWdubWVudCB3aXRoIHRoZQ0KPj4+PiB0ZXJtaW5vbG9neSB1c2VkIGluIGF2dGV4 dKGvcyBncm91cGluZyB0YXhvbm9teSBkcmFmdCwgYW5kIGEgcmV3cml0ZSBvZg0KPj4+PiBzZWN0 aW9uIDMuMTAgKHNwbGl0LWNvbXBvbmVudCB0ZXJtaW5hbCkuDQo+Pj4+IA0KPj4+PiBBcyBwZXIg Z3VpZGFuY2UgcmVjZWl2ZWQgaW4gVG9yb250bywgSSBkaWQgaW5jbHVkZSBjb3B5LXBhc3RlcyBv Zg0KPj4+PnRob3NlDQo+Pj4+IGZldyBkZWZpbml0aW9ucyBvZiB0aGUgdGF4b25vbXkgZHJhZnQg cmVxdWlyZWQgaGVyZWluLCBzbyB0byBrZWVwIHRoZQ0KPj4+PiB0d28NCj4+Pj4gZHJhZnRzIGlu ZGVwZW5kZW50LiAgSG93ZXZlciwgSSBoYXZlIGFsc28gYXNrZWQgdGhlIFJGQyBlZGl0b3IgdG8N Cj4+Pj4gcmVwbGFjZQ0KPj4+PiB0aG9zZSBkZWZpbml0aW9ucyB3aXRoIGEgcmVmZXJlbmNlIHRv IGEgZm9ydGhjb21pbmcgdGF4b25vbXktUkZDLCBpZg0KPj4+PiBzdWNoDQo+Pj4+IGNhbiBiZSBk b25lIHdpdGhvdXQgdW5kdWUgZGVsYXkuICBTZWUgc2VjdGlvbiAyLjIuDQo+Pj4+IA0KPj4+PiBT ZWN0aW9uIDMuMTAgd2FzIGNsb3NlIHRvIHVucGFyc2FibGUtLWF0IGxlYXN0IHZlcnkgY29uZnVz aW5nLS13aGljaA0KPj4+PiB0cmlnZ2VyZWQgdGhlIHJld3JpdGUuICBJIHRoaW5rIGl0oa9zIGJl dHRlciBub3csIGJ1dCBpdCBjZXJ0YWlubHkNCj4+Pj5uZWVkcw0KPj4+PiBhDQo+Pj4+IGZyZXNo IHJldmlldy4NCj4+Pj4gDQo+Pj4+IFRvd2FyZHMgdGhlIGVuZCBvZiB0aGlzIGVtYWlsLCBmaW5k IG15IHJlc3BvbnNlcyB0byBCbyBCdXJtYW6hr3MNCj4+Pj50aG9yb3VnaA0KPj4+PiByZXZpZXcg b2YgdmVyc2lvbiAtMDIsIHBvc3RlZCB0byB0aGlzIGxpc3Qgb24gNi8xMS8xNC4gIEkgaGFkIHBy aXZhdGUNCj4+Pj4gY29tbXVuaWNhdGlvbiB3aXRoIEJvIGR1cmluZyB0aGUgZWRpdGluZyBwcm9j ZXNzLCBhbmQgaGWhr3MgaGFwcHkgd2l0aA0KPj4+PiB0aGUNCj4+Pj4gcmVzdWx0IGFuZCBmb3Vu ZCBoaXMgcG9pbnRzIGFkZHJlc3NlZC4NCj4+Pj4gDQo+Pj4+IE15IGxpc3Qgb2Ygb3BlbiBpc3N1 ZXMgb2YgdGhpcyBkcmFmdCBpcyBub3cgZW1wdHkuICBXR0xDIHdvdWxkIGJlIGZpbmUNCj4+Pj4g d2l0aCBtZS4gIFBsZWFzZSByZXZpZXcsIGNvbW1lbnQsIGFuZCBnZXQgdGhpcyB0aGluZyBvdXQg b2YgdGhlIGRvb3IuDQo+Pj4+IA0KPj4+PiBUaGFua3MsDQo+Pj4+IFN0ZXBoYW4NCj4+Pj4gDQo+ Pj4+IE9uIDYvMTEvMTQsIDI6MzkgQU0sICJCbyBCdXJtYW4iIDxiby5idXJtYW5AZXJpY3Nzb24u Y29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IEhpIGFsbCwNCj4+Pj4gDQo+Pj4+IFtCb10gSSByZXZp ZXdlZCB0aGlzIGFzIGEgcGFydCBvZiB0aGUgb25nb2luZyB1cGRhdGUgb2YgdGhlIHRheG9ub215 DQo+Pj4+IGRyYWZ0DQo+Pj4+IHRvDQo+Pj4+IHRyeSB0byBhbGlnbiB0aGVtLCBhbmQgaGF2ZSB0 aGUgZm9sbG93aW5nIGNvbW1lbnRzIG9uIHRoZQ0KPj4+PiB0b3BvbG9naWVzLXVwZGF0ZS0wMjoN Cj4+Pj4gKiBXaGF0IGlzIG1lYW50IHdpdGggIk1lZGlhIEZsb3ciIGluIDMuMi4xLjM7IGlzIGl0 IGEgc2V0IG9mIFJUUA0KPj4+PiBTdHJlYW1zPw0KPj4+PiBJbiB0aGF0IGNhc2UsIGRvZXMgdGhp cyBzZXQgaGF2ZSBhbnkgc3BlY2lmaWMgY2hhcmFjdGVyaXN0aWNzPw0KPj4+PiANCj4+Pj4gW1N0 V10NCj4+Pj4gDQo+Pj4+IFRoZSBjb21tZW50cyByZWxhdGVzIHRvIHRoZSBkZXNjcmlwdGlvbiBv ZiBGaWcuIDMuICBObywgdGhlIKn4bWVkaWENCj4+Pj5mbG93qfcNCj4+Pj4gaXMgcmVhbGx5IG9u bHkgYSBzaW5nbGUgUlRQIHN0cmVhbSAod2l0aG91dCBGRUMpIHRvIHdoaWNoIEZFQyBpcyBhZGRl ZA0KPj4+PiBieQ0KPj4+PiB0aGUgdHJhbnNsYXRvci4gIFRoZSByZWxldmFudCBwYXJhZ3JhcGgg d2FzIHBvb3JseSBhbmQgb3Zlcmx5IGJyb2FkbHkNCj4+Pj4gd3JpdHRlbiwgYW5kIEkgdGlnaHRl bmVkIHRoZSBsYW5ndWFnZS4NCj4+Pj4gDQo+Pj4+IFtCb10NCj4+Pj4gKiAoQXQgbGVhc3QpIGlu IDMuMi4yIGFuZCAzLjMuMywgdGhlIHRlcm0gImZsb3ciIGlzIHVzZWQgaW4gIlJUUCBmbG93Ig0K Pj4+PiBvcg0KPj4+PiAicGFja2V0IGZsb3ciOyBob3cgaXMgdGhhdCBkaWZmZXJlbnQgZnJvbSB0 YXhvbm9teSBSVFAgU3RyZWFtPw0KPj4+PiANCj4+Pj4gW1N0V10NCj4+Pj4gVmVyeSBnb29kIGNh dGNoOyB0aGUgbGFuZ3VhZ2UgaGVyZSAobW9zdGx5IGZyb20gNTExNykgd2FzIHJlYWxseSBpbg0K Pj4+Pm5lZWQNCj4+Pj4gdG8gYmUgdGlnaHRlbmVkIHVwLiAgSSBjaGVja2VkIHRoZSB2YXJpb3Vz IG9jY3VycmVuY2VzIG9mIKn4Zmxvd6n3LCBhbmQNCj4+Pj4gcmVwbGFjZWQgdGhlbSB3aXRoIKn4 UlRQIHN0cmVhban3IHdoZXJlIGFwcHJvcHJpYXRlLiAgVGhlIHJlbWFpbmluZw0KPj4+PiCp+GZs b3ep93MNCj4+Pj4gYXJlIHRyYW5zcG9ydCBmbG93cywgd2hpY2ggaXMgYmFzaWNhbGx5IHRoZSBm bG93IG9mIHBhY2tldHMgaW4gYQ0KPj4+PiB0cmFuc3BvcnQNCj4+Pj4gYXNzb2NpYXRpb24gKGZp dmUgdHVwbGUpLg0KPj4+PiANCj4+Pj4gW0JvXQ0KPj4+PiAqIFRoZSB0ZXJtcyAidHJhbnNwb3J0 IGZsb3ciIG9yIGp1c3QgImZsb3ciIGFyZSBoZWF2aWx5IHVzZWQgaW4gMy40Ow0KPj4+PiBhZ2Fp biwgYXMgd2l0aCAiTWVkaWEgRmxvdyIsIGlzIHRoZXJlIGFueSBzcGVjaWZpYyBkaXN0aW5jdGlv biBhc3N1bWVkDQo+Pj4+IGluDQo+Pj4+IHRoaXMgYmVzaWRlcyBwb3NzaWJseSBiZWluZyBhIHNl dCBvZiBSVFAgU3RyZWFtcz8NCj4+Pj4gDQo+Pj4+IFtTdFddDQo+Pj4+IFllcywgaW4gMy40LCB0 cmFuc3BvcnQgZmxvdyByZWZlcnMgdG8gcGFja2V0cyBnb2luZyBvdmVyIGEgNSB0dXBsZSwNCj4+ Pj5zZWUNCj4+Pj4gYWJvdmUuICBJIGhvcGUgdGhpcyBpcyBub3cgY2xlYXIgZnJvbSBjb250ZXh0 Lg0KPj4+PiANCj4+Pj4gW0JvXQ0KPj4+PiAqIFRoZSB0ZXJtICJSVFAgbWVkaWEgc3RyZWFtIiBp cyB1c2VkIGluIG1hbnkgcGxhY2VzOyBpcyB0aGVyZSBhbg0KPj4+PiBpbnRlbmRlZCBzcGVjaWFs aXphdGlvbiBjb21wYXJlZCB0byBhIChnZW5lcmljKSBSVFAgU3RyZWFtPw0KPj4+PiANCj4+Pj4g W1N0V10NCj4+Pj4gTm8sIFJUUCBtZWRpYSBzdHJlYW0gYW5kIFJUUCBzdHJlYW0gYXJlIG1lYW50 IHRvIGJlIHRoZSBzYW1lIGluIGFsbA0KPj4+PiBjYXNlcy4NCj4+Pj4gSSB3ZW50IHRocm91Z2gg dGhlIGRvYyBhbmQgZml4ZWQgYXMgYXBwcm9wcmlhdGUsIHVzaW5nIKn4UlRQIHN0cmVhban3DQo+ Pj4+IChob3BlZnVsbHkpIGNvbnNpc3RlbnRseS4NCj4+Pj4gDQo+Pj4+IFtCb10NCj4+Pj4gKiBX aGF0IGlzIGEgIkNvbnRlbnQgc291cmNlIiBpbiAzLjY/IElzIGl0IGEgTWVkaWEgU291cmNlPw0K Pj4+PiANCj4+Pj4gW1N0V10NCj4+Pj4gVHJpY2t5LiAgSW4gMy42LCCp+GNvbnRlbnQgc291cmNl qfcgaXMgdXNlZCB0byBpZGVudGlmeSB0aGUgTWVkaWEgc2VuZGVyDQo+Pj4+IGFzDQo+Pj4+IGEg d2hvbGU6IHVuY29tcHJlc3NlZCBzdHJlYW0gZ2VuZXJhdGlvbiAodGhyb3VnaCBtaXhpbmcgb3IN Cj4+Pj5hY3F1aXNpdGlvbiksDQo+Pj4+IGVuY29kaW5nLCBwYWNrZXRpemluZy4gICCp+EVuZHBv aW50qfcgbWF5IGJlIG1vcmUgYXBwcm9wcmlhdGUuICBIb3dldmVyLA0KPj4+PiB0aGF0IHdvdWxk IGltcGx5IHRoYXQgYSBtaWRkbGVib3ggbGlrZSBhIE1peGVyIG9yIE1DVSBhcmUgYWxzbw0KPj4+ PiBlbmRwb2ludHMsDQo+Pj4+IHdoaWNoIGlzIGNvdW50ZXItaW50dWl0aXZlLCBhdCBsZWFzdCB0 byBtZS4gIEkgdHJpZWQgdG8gd29yZCBhcm91bmQuDQo+Pj4+IA0KPj4+PiBbQm9dDQo+Pj4+ICog V2hhdCBpcyBhICJDb25mZXJlbmNlIHNlc3Npb24iIGluIDMuNj8gSXMgaXQgYSBDb21tdW5pY2F0 aW9uDQo+Pj4+U2Vzc2lvbiwNCj4+Pj4gb3Igc29tZSBzcGVjaWFsaXphdGlvbiBvZiBpdD8NCj4+ Pj4gDQo+Pj4+IFtTdFddDQo+Pj4+IENvbW11bmljYXRpb24gU2Vzc2lvbiBzZWVtcyByaWdodC4N Cj4+Pj4gDQo+Pj4+IFtCb10NCj4+Pj4gKiBDYW4geW91IGV4cGxhaW4gYSBiaXQgb2Ygd2hhdCBp cyBhICJTZXNzaW9uIHBhcnRpY2lwYW50IiBpbiAzLjY/DQo+Pj4+VGhlcmUNCj4+Pj4gYXJlIGRp c2N1c3Npb25zIG9uIHRoZSB1c2Ugb2YgRW5kIFBvaW50IGFuZC9vciBQYXJ0aWNpcGFudCBpbg0K Pj4+PnRheG9ub215LA0KPj4+PiBzbyBJJ20gaGVzaXRhbnQgdG8gc3VnZ2VzdCBhbnkgdGF4b25v bXkgdGVybSByaWdodCBub3cgc2luY2UgaXQgbWF5DQo+Pj4+IGNoYW5nZS4NCj4+Pj4gDQo+Pj4+ IFtTdFddDQo+Pj4+IFNlc3Npb24gcGFydGljaXBhbnRzIHJlZmVycyB0byBSVFAgc2VuZGluZy9y ZWNlaXZpbmcgZW50aXRpZXMgdGhhdA0KPj4+PnRha2UNCj4+Pj4gcGFydCBvZiB0aGUgc2FtZSBS VFAgc2Vzc2lvbi4gIEluc29mYXIsIHRheG9ub215LTAyqfZzIEVuZCBQb2ludCB3b3VsZA0KPj4+ PmJlDQo+Pj4+IGFwcHJvcHJpYXRlLCB3aXRoIHRoZSBhZGRpdGlvbmFsIHJlbWFyayB0aGF0IHRo ZXNlIEVuZCBQb2ludHMgc2hhcmUNCj4+Pj5vbmUNCj4+Pj4gUlRQIHNlc3Npb24uDQo+Pj4+IA0K Pj4+PiBUaGUgd29yZCCp+HBhcnRpY2lwYW50qfcgaXMgdXNlZCB0aHJvdWdob3V0IHRoZSBkb2N1 bWVudCBpbiBhIG51bWJlciBvZg0KPj4+PiBkaWZmZXJlbnQgY29udGV4dHMsIHVzdWFsbHkgYnV0 IG5vdCBhbHdheXMgd2l0aCBhIG1lYW5pbmcgc2ltaWxhciB0bw0KPj4+PkVuZA0KPj4+PiBQb2lu dCBpbiB0YXhvbm9teS4gIEkgaGF2ZSByZXBsYWNlZCCp+HBhcnRpY2lwYW50qfcgd2l0aCCp+EVu ZCBQb2ludKn3DQo+Pj4+d2hlcmUNCj4+Pj4gYXBwcm9wcmlhdGUsIGFuZCBsZWZ0IGl0ICh1c3Vh bGx5IHdpdGggcXVhbGlmaWVycykgb3RoZXJ3aXNlLg0KPj4+PiANCj4+Pj4gW0JvXQ0KPj4+PiAq IFRoZSBzdGFuZC1hbG9uZSB0ZXJtICJzdHJlYW0iIGlzIHVzZWQgaW4gbWFueSBwbGFjZXMgdGhy b3VnaG91dCB0aGUNCj4+Pj4gZG9jdW1lbnQuIEkgdGhpbmsgaXQgdmVyeSByZWFzb25hYmxlIHRv IGp1c3QgYXNzdW1lIGl0IGlzIGEgc2hvcnQgZm9yDQo+Pj4+ICJSVFAgU3RyZWFtIiwgYnV0IHlv dSBtYXkgd2FudCB0byBtYWtlIHN1Y2ggY29tbWVudCBlYXJseSBvbiBpbiB0aGUNCj4+Pj4gZG9j dW1lbnQuIEkgZm91bmQgbm8gcGxhY2UgaW4gdGhlIGRvY3VtZW50IHdoZXJlIHN1Y2ggYXNzdW1w dGlvbiB3b3VsZA0KPj4+PiBiZQ0KPj4+PiBpbnZhbGlkLg0KPj4+PiANCj4+Pj4gW1N0V10NCj4+ Pj4gRml4ZWQgYnkgdXNpbmcgqfhSVFAgc3RyZWFtIGNvbnNpc3RlbnRseS4NCj4+Pj4gDQo+Pj4+ IFtCb10NCj4+Pj4gKiBUaGUgdGVybSAiZ2xvYmFsIHNlc3Npb24iIGlzIHVzZWQgaW4gMy42OyBJ IGZpbmQgaXQgYSBiaXQgaGFyZCB0bw0KPj4+PiB1bmRlcnN0YW5kIHdoYXQgaXMgbWVhbnQuDQo+ Pj4+IA0KPj4+PiBbU3RXXQ0KPj4+PiBJIHRoaW5rIGl0qfZzIKn4Q29tbXVuaWNhdGlvbiBTZXNz aW9uqfcgKGV2ZXJ5IEVuZHBvaW50IGFuZCBldmVyeSBtaWRkbGUNCj4+Pj4gYm94DQo+Pj4+IHRo YXQgYXJlIHRhbGtpbmcgdG8gZWFjaCBvdGhlcikuICBGaXhlZC4NCj4+Pj4gDQo+Pj4+IFtCb10N Cj4+Pj4gKiBTZWN0aW9uIDMuNi4xIGNvdWxkIHBvc3NpYmx5IGJlbmVmaXQgZnJvbSB1c2luZyB0 aGUgdGF4b25vbXkgdGVybQ0KPj4+PiAiRW5jb2RlZCBTdHJlYW0iDQo+Pj4+IA0KPj4+PiBbU3RX XQ0KPj4+PiBDb3JyZWN0LiAgQ2xhcmlmaWVkLg0KPj4+PiANCj4+Pj4gW0JvXQ0KPj4+PiAqIE5p dDogRmlndXJlIDMgKGluIDMuMi4xLjMpIGFuZCBGaWd1cmUgNCAoaW4gMy4yLjIpIGhhdmUgdGhl IHNhbWUNCj4+Pj4gY2FwdGlvbjsgaXMgdGhpcyBpbnRlbmRlZD8NCj4+Pj4gDQo+Pj4+IFtTdFdd DQo+Pj4+IE5vLiAgRml4ZWQuDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBN YWludGVuYW5jZQ0KPj4+PiBhdnRAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hdnQNCj4+PiANCj4+PiANCj4+PiANCj4+PiAtLSANCj4+PiBDb2xp biBQZXJraW5zDQo+Pj4gaHR0cDovL2NzcGVya2lucy5vcmcvDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+ PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPj4gYXZ0QGlldGYub3Jn DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KPg0KPg0KPg0K Pi0tIA0KPkNvbGluIFBlcmtpbnMNCj5odHRwOi8vY3NwZXJraW5zLm9yZy8NCj4NCj4NCj4NCg0K From nobody Fri Aug 8 10:22:32 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E041A017A for ; Fri, 8 Aug 2014 10:22:31 -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 Z22U1IsEUPMq for ; Fri, 8 Aug 2014 10:22:28 -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 5C26B1A0046 for ; Fri, 8 Aug 2014 10:22:28 -0700 (PDT) Received: from [130.209.247.112] (port=59211 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 1XFns1-0004Dv-TD; Fri, 08 Aug 2014 18:22:26 +0100 Content-Type: text/plain; charset=euc-kr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Fri, 8 Aug 2014 18:22:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <716C6558-C1B9-499E-A0A2-93F9111802AA@csperkins.org> References: <3147A00C-8D9D-41FD-8A4B-273972E769B0@csperkins.org> <25F74D0B-5BB2-480F-B4FA-10D226843952@csperkins.org> To: Stephan Wenger 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/avt/q79XDYrQFlHXBgfIuTRtZlgc_1E Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Topologies-update, reply to Bo's review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:22:31 -0000 Hi, On 8 Aug 2014, at 16:20, Stephan Wenger wrote: > On 8/8/14, 7:36 AM, "Colin Perkins" wrote: >> They=A1=AFre logically part of the same endpoint, and use a common = clock, and >> this makes them semantically coupled anyway, so I think a common = CNAME >> and single RTP session makes sense (this is essentially the design = the >> old Mbone tools used to lip-sync when audio and video were done with >> separate tools, using a coordination protocol). >=20 > So let=A1=AFs assume a common CNAME, but also separate transport = addresses per > subunit. Both version 02 and 03 of the draft comment on that scenario = as > follows: >=20 > =A1=B0It is not really feasible to decompose one logical end-point = into two > different transport nodes in one RTP session. A third party monitor = would > report such an attempt as two entities being two different end-points = with > a CNAME collision. As a result, a fully RTP conformant de-composited > endpoint is one where the different decomposed parts use separate RTP > sessions to send and/or receive media streams intended for them." >=20 > You seem to assert that this is a non-issue. Why? I think you=A1=AFre confusing transport-layer flows and RTP sessions, = and the role of the CNAME. It=A1=AFs a non-issue because the =A1=B0CNAME = collision=A1=B1 is normal, and orthogonal to the number of RTP sessions = or transport-layer flows. Assume I want to send you audio and video flows that can be synchronised = on playout. I=A1=AFll send two RTP streams, one for the audio and one = for the video, using a different SSRC for each stream, and mapping their = media clocks to a common reference clock, which is reported in RTCP SR = packets. The RTCP SDES packets for each SSRC will use the same CNAME, = and it=A1=AFs that common CNAME that indicates to the receiver that the = two flows can be synchronised. The receiver also has its own two SSRC = values, one for the audio and one for video, that it includes in the = RTCP RR packets it sends (and also for any audio and video RTP packets = it sends back). The RTP streams can be multiplexed onto a single 5-tuple, for example: Sender Receiver +-------------------+ +------------------+ =20 | IP addr 10.0.0.1 | | IP addr 10.0.0.2 | | | | | | +-----+SSRC 1111 | | SSRC 3333+-----+ | | |Audio|<-----+ | | +---->|Audio| | | +-----+ |Port| |Port| +-----+ | | +=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D+ = | | +-----+ |5000| |6000| +-----+ | | |Video|<-----+ | | +---->|Video| | | +-----+SSRC 2222 | | SSRC 4444+-----+ | | | | | +-------------------+ +------------------+ There is a single transport-layer flow, from 10.0.0.1:5000 to = 10.0.0.2:6000. RTP packets with two SSRC values are multiplexed on that = flow from sender to receiver, and RTCP packets with two SSRC values are = multiplexed on that flow in the reverse direction. In this case, both = SSRCs at the receiver can see the packets sent by both sender SSRCs, = since they all arrive on the same port. The RTCP sent by SSRC 3333 will = contain RTCP RR packets relating both to SSRC 1111 and SSRC 2222, as = will the RTCP sent by SSRC 4444. This gives a single RTP session, since = each SSRC can see every other SSRC. The RTCP reports sent by SSRC 1111 = and SSRC 2222 will both use the same CNAME, to indicate that they can be = synchronised. The RTP streams can also be sent using distinct 5-tuples, for example: Sender Receiver +-------------------+ +------------------+ =20 | IP addr 10.0.0.1 | | IP addr 10.0.0.2 | | | | | | +-----+ Port 5000 | |Port 6000 +-----+ | | |Audio|-----------+-------+--------->|Audio| | | +-----+ SSRC 1111 | |SSRC 3333 +-----+ | | | | : | | +-----+ Port 5002 | |Port 6002 +-----+ | | |Video|-----------+-------+--------->|Video| | | +-----+ SSRC 2222 | |SSRC 4444 +-----+ | | | | | +-------------------+ +------------------+ This has two transport-layer flows, one from 10.0.0.1:5000 to = 10.0.0.2:6000, and the other from 10.0.0.1:5002 to 10.0.0.2:6002. One of = those flows carries audio, the other carries video. If SSRC 3333 only sends RTCP reports relating to SSRC 1111, and SSRC = 4444 only sends RTCP reports relating to SSRC 2222, then this scenario = comprises two RTP sessions. However, if the receiver is implemented such = that SSRC 3333 and SSRC 4444 share reception quality information, and = each of SSRC 3333 and SSRC 4444 send RTCP reports relating to both SSRC = 1111 and SSRC 2222, then there is only a single RTP session, despite the = use of multiple transport-layer flows, since each SSRC can see every = other SSRC.=20 No matter whether how the receiver is implemented, RTCP packets sent by = SSRC 1111 and by SSRC 222 will use the same CNAME, to indicate that they = can be synchronised, even though they are sent on separate = transport-layer flows. We can split things up further, to the distinct 5-tuples come from = different IP addresses (this is a version of Topo-Split-Terminal): Sender Receiver +-------------------+ +------------------+ =20 | IP addr 10.0.0.1 | | IP addr 10.0.0.2 | | | | | | +-----+ Port 5000 | |Port 6000 +-----+ | | |Audio|<----------+-------+--------->|Audio| | | +-----+ SSRC 1111 | |SSRC 3333 +-----+ | +---+---------------+ | : | |clock sync | : | +---+---------------+ | : | | IP addr 10.0.1.1 | | : | | +-----+ Port 5002 | |Port 6004 +-----+ | | |Video|<----------+-------+--------->|Video| | | +-----+ SSRC 2222 | |SSRC 4444 +-----+ | | | | | +-------------------+ +------------------+ Again, there are two transport layer flows, and again this can be either = one or two RTP sessions, depending on whether the two SSRCs in the = Receiver share information (i.e., if the RTCP packets that SSRC 3333 = sends include reports relating to both SSRC 1111 and SSRC 2222, and = similarly for SSRC 4444, then each SSRC can see every other, and there = is a single RTP session; however, if SSRC 3333 only reports on SSRC = 1111, and SSRC 4444 only reports on SSRC 2222, then there are two RTP = sessions). Again, irrespective of receiver behaviour, and the number of = RTP sessions, RTCP packets sent by SSRC 1111 and SSRC 2222 will use the = same CNAME to indicate that their flows can be synchronised (they need = to run a clock synchronisation protocol to ensure they have access to = the common clock). If you want to decompose an endpoint, sending audio and video from = separate transport-layer addresses and allowing the receiver to = synchronise the flows, then the audio and video need to use different = SSRCs, but the same CNAME, and use some (non-RTP) clock synchronisation = protocol. Whether those flows form a single RTP session or not depends = on whether the system is implemented to share a single SSRC space and = single view of the reception quality, or not. Topo-Split-Terminal can = therefore be implemented using multiple RTP sessions, or using a single = RTP session (although neither affects the choice of CNAME). I would argue that implementing this topology as a single RTP session = could be beneficial, since the cross reporting provides information = that=A1=AFs helpful for (potentially automated) debugging of reception = quality problems. Others would doubtless say the cross-reporting is = unnecessary overhead, and would prefer to implement this as separate RTP = sessions. Both are valid views, with different trade-offs. --=20 Colin Perkins http://csperkins.org/ From nobody Fri Aug 8 10:45:50 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E17E1A00D5 for ; Fri, 8 Aug 2014 10:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 iBsvrCs40uYm for ; Fri, 8 Aug 2014 10:45:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B721A007D for ; Fri, 8 Aug 2014 10:45:45 -0700 (PDT) Received: from CO1PR07MB362.namprd07.prod.outlook.com (10.141.75.21) by CO1PR07MB863.namprd07.prod.outlook.com (10.242.163.156) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 8 Aug 2014 17:45:42 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB362.namprd07.prod.outlook.com (10.141.75.21) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 8 Aug 2014 17:45:39 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.136]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.136]) with mapi id 15.00.0995.014; Fri, 8 Aug 2014 17:45:39 +0000 From: Stephan Wenger To: Colin Perkins Thread-Topic: [AVTCORE] Topologies-update, reply to Bo's review Thread-Index: AQHPspVWg15Q2HN36EeDlcGGcl3C3pvGvOWA//+TPwCAAHcNAP//lsSAgACXf4D//5EhgA== Date: Fri, 8 Aug 2014 17:45:38 +0000 Message-ID: References: <3147A00C-8D9D-41FD-8A4B-273972E769B0@csperkins.org> <25F74D0B-5BB2-480F-B4FA-10D226843952@csperkins.org> <716C6558-C1B9-499E-A0A2-93F9111802AA@csperkins.org> In-Reply-To: <716C6558-C1B9-499E-A0A2-93F9111802AA@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(189002)(164054003)(51704005)(479174003)(377454003)(199002)(92566001)(106356001)(76176999)(50986999)(36756003)(83322001)(110136001)(76482001)(54356999)(74502001)(80022001)(83072002)(77982001)(19580405001)(85852003)(19580395003)(99286002)(4396001)(95666004)(105586002)(85306004)(106116001)(74662001)(93886004)(15202345003)(31966008)(101416001)(77096002)(20776003)(46102001)(15395725005)(92726001)(107046002)(86362001)(64706001)(21056001)(2656002)(87936001)(81542001)(66066001)(15975445006)(81342001)(79102001)(99396002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB362; H:CO1PR07MB363.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/avt/KhLG5ZCFEFOoZptfNzbb47NjSy0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Topologies-update, reply to Bo's review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:45:49 -0000 Hi Colin, I think I start seeing your point. Let me work on section 3.10 a bit more (over the weekend most likely). But please also see inline (towards the top of the thread only). Thanks, Stephan =20 On 8/8/14, 10:22 AM, "Colin Perkins" wrote: >Hi, > >On 8 Aug 2014, at 16:20, Stephan Wenger wrote: >> On 8/8/14, 7:36 AM, "Colin Perkins" wrote: >>> They=B9re logically part of the same endpoint, and use a common clock, >>>and >>> this makes them semantically coupled anyway, so I think a common CNAME >>> and single RTP session makes sense (this is essentially the design the >>> old Mbone tools used to lip-sync when audio and video were done with >>> separate tools, using a coordination protocol). >>=20 >> So let=B9s assume a common CNAME, but also separate transport addresses >>per >> subunit. Both version 02 and 03 of the draft comment on that scenario >>as >> follows: >>=20 >> =B3It is not really feasible to decompose one logical end-point into two >> different transport nodes in one RTP session. This is the statement you question. You argue it is possible and still stay compliant with RTP. >>A third party monitor would >> report such an attempt as two entities being two different end-points >>with >> a CNAME collision. Do I understand you correctly that yes, a third party monitor would indeed report a CNAME collision, but that=B9s a problem of the third party monitor= . Or, better, the third party monitor=B9s lack of awareness of the existence of decomposed endpoint subunits in the same RTP session, them being a legal (and, in at least some scenarios, even desirable) design choice. >>As a result, a fully RTP conformant de-composited >> endpoint is one where the different decomposed parts use separate RTP >> sessions to send and/or receive media streams intended for them." And this is, according to you, an incorrect statement. >>=20 >> You seem to assert that this is a non-issue. Why? > >I think you=B9re confusing transport-layer flows and RTP sessions, and the >role of the CNAME. It=B9s a non-issue because the =B3CNAME collision=B2 is >normal, and orthogonal to the number of RTP sessions or transport-layer >flows. > >Assume I want to send you audio and video flows that can be synchronised >on playout. I=B9ll send two RTP streams, one for the audio and one for the >video, using a different SSRC for each stream, and mapping their media >clocks to a common reference clock, which is reported in RTCP SR packets. >The RTCP SDES packets for each SSRC will use the same CNAME, and it=B9s >that common CNAME that indicates to the receiver that the two flows can >be synchronised. The receiver also has its own two SSRC values, one for >the audio and one for video, that it includes in the RTCP RR packets it >sends (and also for any audio and video RTP packets it sends back). > >The RTP streams can be multiplexed onto a single 5-tuple, for example: > > Sender Receiver > +-------------------+ +------------------+ > | IP addr 10.0.0.1 | | IP addr 10.0.0.2 | > | | | | > | +-----+SSRC 1111 | | SSRC 3333+-----+ | > | |Audio|<-----+ | | +---->|Audio| | > | +-----+ |Port| |Port| +-----+ | > | +=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D+ = | > | +-----+ |5000| |6000| +-----+ | > | |Video|<-----+ | | +---->|Video| | > | +-----+SSRC 2222 | | SSRC 4444+-----+ | > | | | | > +-------------------+ +------------------+ > >There is a single transport-layer flow, from 10.0.0.1:5000 to >10.0.0.2:6000. RTP packets with two SSRC values are multiplexed on that >flow from sender to receiver, and RTCP packets with two SSRC values are >multiplexed on that flow in the reverse direction. In this case, both >SSRCs at the receiver can see the packets sent by both sender SSRCs, >since they all arrive on the same port. The RTCP sent by SSRC 3333 will >contain RTCP RR packets relating both to SSRC 1111 and SSRC 2222, as will >the RTCP sent by SSRC 4444. This gives a single RTP session, since each >SSRC can see every other SSRC. The RTCP reports sent by SSRC 1111 and >SSRC 2222 will both use the same CNAME, to indicate that they can be >synchronised. > >The RTP streams can also be sent using distinct 5-tuples, for example: > > Sender Receiver > +-------------------+ +------------------+ > | IP addr 10.0.0.1 | | IP addr 10.0.0.2 | > | | | | > | +-----+ Port 5000 | |Port 6000 +-----+ | > | |Audio|-----------+-------+--------->|Audio| | > | +-----+ SSRC 1111 | |SSRC 3333 +-----+ | > | | | : | > | +-----+ Port 5002 | |Port 6002 +-----+ | > | |Video|-----------+-------+--------->|Video| | > | +-----+ SSRC 2222 | |SSRC 4444 +-----+ | > | | | | > +-------------------+ +------------------+ > >This has two transport-layer flows, one from 10.0.0.1:5000 to >10.0.0.2:6000, and the other from 10.0.0.1:5002 to 10.0.0.2:6002. One of >those flows carries audio, the other carries video. > >If SSRC 3333 only sends RTCP reports relating to SSRC 1111, and SSRC 4444 >only sends RTCP reports relating to SSRC 2222, then this scenario >comprises two RTP sessions. However, if the receiver is implemented such >that SSRC 3333 and SSRC 4444 share reception quality information, and >each of SSRC 3333 and SSRC 4444 send RTCP reports relating to both SSRC >1111 and SSRC 2222, then there is only a single RTP session, despite the >use of multiple transport-layer flows, since each SSRC can see every >other SSRC.=20 > >No matter whether how the receiver is implemented, RTCP packets sent by >SSRC 1111 and by SSRC 222 will use the same CNAME, to indicate that they >can be synchronised, even though they are sent on separate >transport-layer flows. > >We can split things up further, to the distinct 5-tuples come from >different IP addresses (this is a version of Topo-Split-Terminal): > > Sender Receiver > +-------------------+ +------------------+ > | IP addr 10.0.0.1 | | IP addr 10.0.0.2 | > | | | | > | +-----+ Port 5000 | |Port 6000 +-----+ | > | |Audio|<----------+-------+--------->|Audio| | > | +-----+ SSRC 1111 | |SSRC 3333 +-----+ | > +---+---------------+ | : | > |clock sync | : | > +---+---------------+ | : | > | IP addr 10.0.1.1 | | : | > | +-----+ Port 5002 | |Port 6004 +-----+ | > | |Video|<----------+-------+--------->|Video| | > | +-----+ SSRC 2222 | |SSRC 4444 +-----+ | > | | | | > +-------------------+ +------------------+ > >Again, there are two transport layer flows, and again this can be either >one or two RTP sessions, depending on whether the two SSRCs in the >Receiver share information (i.e., if the RTCP packets that SSRC 3333 >sends include reports relating to both SSRC 1111 and SSRC 2222, and >similarly for SSRC 4444, then each SSRC can see every other, and there is >a single RTP session; however, if SSRC 3333 only reports on SSRC 1111, >and SSRC 4444 only reports on SSRC 2222, then there are two RTP >sessions). Again, irrespective of receiver behaviour, and the number of >RTP sessions, RTCP packets sent by SSRC 1111 and SSRC 2222 will use the >same CNAME to indicate that their flows can be synchronised (they need to >run a clock synchronisation protocol to ensure they have access to the >common clock). > >If you want to decompose an endpoint, sending audio and video from >separate transport-layer addresses and allowing the receiver to >synchronise the flows, then the audio and video need to use different >SSRCs, but the same CNAME, and use some (non-RTP) clock synchronisation >protocol. Whether those flows form a single RTP session or not depends on >whether the system is implemented to share a single SSRC space and single >view of the reception quality, or not. Topo-Split-Terminal can therefore >be implemented using multiple RTP sessions, or using a single RTP session >(although neither affects the choice of CNAME). > >I would argue that implementing this topology as a single RTP session >could be beneficial, since the cross reporting provides information >that=B9s helpful for (potentially automated) debugging of reception qualit= y >problems. Others would doubtless say the cross-reporting is unnecessary >overhead, and would prefer to implement this as separate RTP sessions. >Both are valid views, with different trade-offs. > >--=20 >Colin Perkins >http://csperkins.org/ > > > From nobody Sat Aug 9 11:49:21 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A593D1A0196; Sat, 9 Aug 2014 11:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 vSQSEH-718yU; Sat, 9 Aug 2014 11:48: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 C66561A0009; Sat, 9 Aug 2014 11:48: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 s79ImD3G015211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 9 Aug 2014 13:48:15 -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 13:48:13 -0500 X-Mao-Original-Outgoing-Id: 429302893.093861-e61d2b4180cda6697e5d18b3ca4c2570 Content-Transfer-Encoding: quoted-printable Message-Id: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> References: To: tsvwg@ietf.org, avt@ietf.org, "clue@ietf.org" , mmusic@ietf.org, rtcweb@ietf.org, rmcat@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/avt/iPPHsl8vlr6_GneV9s3aFcPN1Zc Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org Subject: [AVTCORE] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 18:48:24 -0000 Hi, The DART working group has started a last call for = draft-ietf-dart-dscp-rtp-02, ending on August 22. This informational = draft describes considerations for the use of DiffServ code points in = situations where one multiplexes multiple RTP packet streams, and = potentially other protocol streams, that share the same 5-tuple.=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. 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 >=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 From nobody Sat Aug 9 22:57:36 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41F71A0644 for ; Sat, 9 Aug 2014 22:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.733 X-Spam-Level: X-Spam-Status: No, score=0.733 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, 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 nW_cql-UeB1g for ; Sat, 9 Aug 2014 22:57:34 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211881A0643 for ; Sat, 9 Aug 2014 22:57:34 -0700 (PDT) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id s7A5vMPF086608; Sat, 9 Aug 2014 22:57:22 -0700 (PDT) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_7BB2D237-67B6-4AE4-ACF0-34F669F18416" Date: Sat, 9 Aug 2014 22:57:22 -0700 Message-Id: To: mbaugher@cisco.com, elisabetta.carrara@ericsson.com, mcgrew@cisco.com, mats.naslund@ericsson.com, karl.norrman@ericsson.com Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/avt/OBN3vzc_RFRN58_zI6AG7DRU6fU Cc: avt@ietf.org Subject: [AVTCORE] Minor bug in RFC 3711 (SRTP), FYI X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 05:57:35 -0000 --Apple-Mail=_7BB2D237-67B6-4AE4-ACF0-34F669F18416 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In section 3.4 ("Secure RTCP"), there is a bug in "Figure 2. An example = of the format of a Secure RTCP packet..." 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |V=3D2|P| RC | PT=3DSR or RR | length = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | The boundary between the "PT=3DSR or RR" and the "length" fields is = wrong: The boundary is shown as being between bits 16 and 17; it should = be between bits 15 and 16. I.e., the "PT=3DSR or RR" field should be 8 = bits long, not 9. This is just a minor bug, because the equivalent diagram in RFC 3550 = (the normative reference for RTCP) is correct. Nonetheless, this bug = should probably be added to the errata for RFC 3711 Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_7BB2D237-67B6-4AE4-ACF0-34F669F18416 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii In = section 3.4 ("Secure RTCP"), there is a bug in "Figure 2. An = example of the format of a Secure RTCP = packet..."

      0     =               1       =             2         =           3
      0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
    =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= ;+
     |V=3D2|P|    RC   | =   PT=3DSR or RR   |             = length          | |
    =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = |

The boundary between the "PT=3DSR or = RR" and the "length" fields is wrong: The boundary is shown as being = between bits 16 and 17; it should be between bits 15 and 16.  I.e., = the "PT=3DSR or RR" field should be 8 bits long, not = 9.

This is just a minor bug, because the = equivalent diagram in RFC 3550 (the normative reference for RTCP) is = correct.  Nonetheless, this bug should probably be added to the = errata for RFC 3711

Ross Finlayson
Live = Networks, Inc.
http://www.live555.com/=

= --Apple-Mail=_7BB2D237-67B6-4AE4-ACF0-34F669F18416-- From nobody Mon Aug 11 01:47:02 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7361A0380 for ; Mon, 11 Aug 2014 01:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 h0-DOm1DUtf8 for ; Mon, 11 Aug 2014 01:46:59 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008EA1A037D for ; Mon, 11 Aug 2014 01:46:58 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-18-53e8830167ae Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id ED.79.21334.10388E35; Mon, 11 Aug 2014 10:46:57 +0200 (CEST) Received: from ESESSMB305.ericsson.se ([169.254.5.45]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Mon, 11 Aug 2014 10:46:56 +0200 From: Yi Cheng To: "avt@ietf.org" Thread-Topic: Comments on SRTP EKT Thread-Index: Ac+1QE3uDrlc/iLwRXSraimwecqpMQ== Date: Mon, 11 Aug 2014 08:46:56 +0000 Message-ID: <9D746FA33933A44198056E8E591AAB5B10554B6A@ESESSMB305.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_9D746FA33933A44198056E8E591AAB5B10554B6AESESSMB305erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvjS5j84tgg8cPRS1e9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxup7fcwFk/oZK+Y9F2tgXNHN2MXIySEhYCKx5PZjdghbTOLC vfVsXYxcHEICRxklDjzrhXIWM0q8vPuEGaSKTUBN4u+916wgtoiAokTrtc9Akzg4hAVkJZ4e UoIIK0ms+7eEEcLWk1i9cRMTiM0ioCrR+vU2mM0r4Cvx/PpBsDGMQIu/n1oDFmcWEJe49WQ+ E8RBAhJL9pxnhrBFJV4+/scKYStKfHy1jxGiPl/i5NNLjBAzBSVOznzCMoFRaBaSUbOQlM1C UjYL6GpmAU2J9bv0IUoUJaZ0P2SHsDUkWufMZUcWX8DIvopRtDi1uDg33chYL7UoM7m4OD9P Ly+1ZBMjMCYObvmtu4Nx9WvHQ4wCHIxKPLwLlF8EC7EmlhVX5h5ilOZgURLnXXRuXrCQQHpi SWp2ampBalF8UWlOavEhRiYOTqkGxuyNRwtYOtLSpxnZu8qLsMziTfw9acKHZboc+ZfPdjVp 2m1c2upqsTnvb9St81t3N/yMN+S66x9au2vatp2KqfznXLXFrQ5/66/obE3l9zR33L75f/D+ l/LHFs04Hsb4zi3+5QdJw2MT/+6a39VZpFo0f3tslZPX9VepepZfj2sXqKQyaAeqKbEUZyQa ajEXFScCAAwW1LBqAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/avt/UTWK7yzok-ppQS_hjB6y8ZB9I9U Subject: [AVTCORE] Comments on SRTP EKT X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 08:47:01 -0000 --_000_9D746FA33933A44198056E8E591AAB5B10554B6AESESSMB305erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VuZCBhIHByZXZpb3VzIGVtYWlsIHdpdGggRXJpY3Nzb27igJlzIGNvbW1lbnRzIG9uIFNSVFAg RUtUIHRvIHRoZSBsaXN0Lg0KDQpCZXN0IHJlZ2FyZHMsDQpZaQ0KDQpGcm9tOiBZaSBDaGVuZw0K U2VudDogZGVuIDE0IG1haiAyMDE0IDA5OjAxDQpUbzogJ2R3aW5nQGNpc2NvLmNvbSc7ICdmYW5k cmVhc0BjaXNvYy5jb20nDQpDYzogTWFnbnVzIFdlc3Rlcmx1bmQ7IEpvaG4gTWF0dHNzb24NClN1 YmplY3Q6IFJFOiBNSUtFWSBjb21tZW50cyBieSBGbGVtbWluZw0KDQpIaSwNCg0KSm9obiBhbmQg bWUgaGF2ZSByZXZpZXdlZCB0aGUgTUlLRVkgcGFydCBvZiB0aGUgRUtUIEludGVybmV0IERyYWZ0 LiBXZSBzZWUgdGhlIGZvbGxvd2luZyBpc3N1ZXMgKEZsZW1taW5nIGhhcyBzaW1pbGFyIGNvbW1l bnRzIGluIEZTQSA0OSwgRlNBIDUwIGFuZCBGU0EgNTQpOg0KDQoxKSAgICAgIFNlY3Rpb24gNSBz cGVjaWZpZXMgb25seSBob3cgdGhlIEVLVCBwYXJhbWV0ZXJzIChpLmUuIGNpcGhlciwga2V5LCBT UEkpIGFyZSB0byBiZSB0cmFuc3BvcnRlZCBpbiB0aGUgTUlLRVkgbWVzc2FnZS4gSG93IHRoZSBT UlRQIHBhcmFtZXRlcnMgYXJlIG5lZ290aWF0ZWQgaXMgbm90IG1lbnRpb25lZC4NCg0KMikgICAg ICBBcyBjdXJyZW50bHkgc3BlY2lmaWVkIGluIHNlY3Rpb24gNS4xLCB3aGVuIEVLVCBpcyB1c2Vk IHRvZ2V0aGVyIHdpdGggTUlLRVksIHdlIHdpbGwgaGF2ZSBhICBTZWN1cml0eSBQb2xpY3kgKFNQ KSBwYXlsb2FkIHdpdGggRUtUIGFzIHRoZSBQcm90IHR5cGUgYW5kIEVLVCBjaXBoZXIgYXMgdGhl IHBhcmFtZXRlci4gQnV0IHdlIGFsc28gbmVlZCBhbm90aGVyIFNQIHBheWxvYWQgdG8gY29tbXVu aWNhdGUgU1JUUCBwYXJhbWV0ZXJzLiBXaGF0IENTIElEIG1hcCBpbmZvIHNoYWxsIGJlIGdpdmVu IGluIHRoZSBDb21tb24gSGVhZGVyIHRoZW4/IEl04oCZcyBub3QgcG9zc2libGUgdG8gaGF2ZSB0 d28gcG9saWNpZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1lIENTLg0KDQpPbmUgcG9zc2libGUg c29sdXRpb24gaXMgdG8gaW5jbHVkZSB0aGUgRUtUIGNpcGhlciBhbmQgRUtUIFNQSSBpbiB0aGUg U1JUUCBwb2xpY3kuIFNvIHdlIGhhdmUgYSBzaW5nbGUgcG9saWN5IHdpdGggYm90aCBTUlRQIHBh cmFtZXRlcnMgYW5kIEVLVCBwYXJhbWV0ZXJzLCBhdm9pZGluZyB0aGUgbWFwcGluZyBwcm9ibGVt IGluIDIpLiBFS1QgU1BJIGNhbiB0aGVuIGJlIHVzZWQgdG8gcmV0cmlldmUgdGhlIEVLVCBwYXJh bWV0ZXIgc2V0LCBhcyBzcGVjaWZpZWQgaW4gc2VjdGlvbiAyLjEuIElmIHdlIGdvIGZvciB0aGlz IHdlIG5lZWQgdG8gYWRkIEVLVCBTUEkgYW5kIGNpcGhlciB0byB0aGUgU1JUUCBwb2xpY3kgcGFy YW1ldGVyIGxpc3QgKHNlY3Rpb24gNi4xMC4xIG9mIFJGQyAzODMwKSBhbmQgcmVtb3ZlIHRoZSBF S1Qgc2VjdXJpdHkgcG9saWN5IGFuZCBjaXBoZXIgcGFyYW1ldGVyIGZyb20gc2VjdGlvbiA1LjEu DQoNCldlIGNhbiB0cmFuc3BvcnQgYm90aCBFS1Qga2V5IGFuZCBUR0sgaW4gdGhlIEtFTUFDIHBh eWxvYWQuIFRoaXMgbWFrZXMgaXQgcG9zc2libGUgdG8gcHJvY2VzcyByZWNlaXZlZCBTUlRQIHBh Y2tldHMgYmVmb3JlIHRoZSBmaXJzdCB2YWxpZCBFS1QgcGFja2V0IGFycml2ZXMsIGxpa2UgaW4g dGhlIGNhc2Ugb2YgY29tYmluZWQgRUtUIGFuZCBTRFAgU2VjdXJpdHkgRGVzY3JpcHRpb24uIFRo ZSBFS1Qga2V5IGhhcyBLViA9IDEgKFNQSSkgYW5kIFRHSyBLViA9IE5VTEwgKG5vdGUgd2UgY2Fu bm90IGhhdmUgbXVsdGlwbGUgVEdLcyBpbiB0aGUgc2FtZSBNSUtFWSBtZXNzYWdlIHNpbmNlIE1L SSBpcyBub3QgYWxsb3dlZCB3aXRoIEVLVCkuDQoNCldoYXQgZG8geW91IChDaXNjbykgdGhpbms/ IERvZXMgaXQgbWFrZSBzZW5zZSB0byB0cmFuc3BvcnQgYm90aCBFS1Qga2V5IGFuZCBUR0sgaW4g TUlLRVkgb3IgZG8geW91IHByZWZlciB0byB1c2UgTUlLRVkgdG8gdHJhbnNwb3J0IEVLVCBrZXkg b25seT8NCg0KQmVzdCByZWdhcmRzLA0KWWkgQ2hlbmcNCg0KRXJpY3Nzb24gUmVzZWFyY2gNCjE2 NDgwIFN0b2NraG9sbQ0KU3dlZGVuDQoNCg0K --_000_9D746FA33933A44198056E8E591AAB5B10554B6AESESSMB305erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQ YXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21z by1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQpwLnhtc29ub3JtYWwsIGxpLnhtc29ub3JtYWwsIGRpdi54bXNvbm9ybWFsDQoJe21zby1z dHlsZS1uYW1lOnhfbXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDoxMjY0NzI0MzY3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczo3MTc0OTQyMTAgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0 O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206 MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+U2VuZCBhIHByZXZpb3VzIGVtYWlsIHdpdGggRXJpY3Nzb27igJlzIGNv bW1lbnRzIG9uIFNSVFAgRUtUIHRvIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFlpIENo ZW5nDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDE0IG1haiAyMDE0IDA5OjAxPGJyPg0KPGI+VG86 PC9iPiAnZHdpbmdAY2lzY28uY29tJzsgJ2ZhbmRyZWFzQGNpc29jLmNvbSc8YnI+DQo8Yj5DYzo8 L2I+IE1hZ251cyBXZXN0ZXJsdW5kOyBKb2huIE1hdHRzc29uPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJFOiBNSUtFWSBjb21tZW50cyBieSBGbGVtbWluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkpvaG4gYW5kIG1lIGhhdmUgcmV2aWV3ZWQgdGhlIE1JS0VZ IHBhcnQgb2YgdGhlIEVLVCBJbnRlcm5ldCBEcmFmdC4gV2Ugc2VlIHRoZSBmb2xsb3dpbmcgaXNz dWVzIChGbGVtbWluZyBoYXMgc2ltaWxhciBjb21tZW50cyBpbiBGU0EgNDksIEZTQSA1MCBhbmQg RlNBIDU0KTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xKTxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gNSBzcGVjaWZpZXMgb25seSBob3cgdGhl IEVLVCBwYXJhbWV0ZXJzIChpLmUuIGNpcGhlciwga2V5LCBTUEkpIGFyZSB0byBiZSB0cmFuc3Bv cnRlZCBpbiB0aGUgTUlLRVkgbWVzc2FnZS4gSG93IHRoZSBTUlRQIHBhcmFtZXRlcnMgYXJlIG5l Z290aWF0ZWQNCiBpcyBub3QgbWVudGlvbmVkLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4y KTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIGN1cnJlbnRs eSBzcGVjaWZpZWQgaW4gc2VjdGlvbiA1LjEsIHdoZW4gRUtUIGlzIHVzZWQgdG9nZXRoZXIgd2l0 aCBNSUtFWSwgd2Ugd2lsbCBoYXZlIGEgJm5ic3A7U2VjdXJpdHkgUG9saWN5IChTUCkgcGF5bG9h ZCB3aXRoIEVLVCBhcyB0aGUgUHJvdCB0eXBlDQogYW5kIEVLVCBjaXBoZXIgYXMgdGhlIHBhcmFt ZXRlci4gQnV0IHdlIGFsc28gbmVlZCBhbm90aGVyIFNQIHBheWxvYWQgdG8gY29tbXVuaWNhdGUg U1JUUCBwYXJhbWV0ZXJzLiBXaGF0IENTIElEIG1hcCBpbmZvIHNoYWxsIGJlIGdpdmVuIGluIHRo ZSBDb21tb24gSGVhZGVyIHRoZW4/IEl04oCZcyBub3QgcG9zc2libGUgdG8gaGF2ZSB0d28gcG9s aWNpZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1lIENTLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T25lIHBvc3NpYmxl IHNvbHV0aW9uIGlzIHRvIGluY2x1ZGUgdGhlIEVLVCBjaXBoZXIgYW5kIEVLVCBTUEkgaW4gdGhl IFNSVFAgcG9saWN5LiBTbyB3ZSBoYXZlIGEgc2luZ2xlIHBvbGljeSB3aXRoIGJvdGggU1JUUCBw YXJhbWV0ZXJzIGFuZCBFS1QgcGFyYW1ldGVycywNCiBhdm9pZGluZyB0aGUgbWFwcGluZyBwcm9i bGVtIGluIDIpLiBFS1QgU1BJIGNhbiB0aGVuIGJlIHVzZWQgdG8gcmV0cmlldmUgdGhlIEVLVCBw YXJhbWV0ZXIgc2V0LCBhcyBzcGVjaWZpZWQgaW4gc2VjdGlvbiAyLjEuIElmIHdlIGdvIGZvciB0 aGlzIHdlIG5lZWQgdG8gYWRkIEVLVCBTUEkgYW5kIGNpcGhlciB0byB0aGUgU1JUUCBwb2xpY3kg cGFyYW1ldGVyIGxpc3QgKHNlY3Rpb24gNi4xMC4xIG9mIFJGQyAzODMwKSBhbmQgcmVtb3ZlIHRo ZSBFS1QNCiBzZWN1cml0eSBwb2xpY3kgYW5kIGNpcGhlciBwYXJhbWV0ZXIgZnJvbSBzZWN0aW9u IDUuMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPldlIGNhbiB0cmFuc3BvcnQgYm90aCBFS1Qga2V5IGFuZCBUR0sgaW4g dGhlIEtFTUFDIHBheWxvYWQuIFRoaXMgbWFrZXMgaXQgcG9zc2libGUgdG8gcHJvY2VzcyByZWNl aXZlZCBTUlRQIHBhY2tldHMgYmVmb3JlIHRoZSBmaXJzdCB2YWxpZCBFS1QgcGFja2V0IGFycml2 ZXMsDQogbGlrZSBpbiB0aGUgY2FzZSBvZiBjb21iaW5lZCBFS1QgYW5kIFNEUCBTZWN1cml0eSBE ZXNjcmlwdGlvbi4gVGhlIEVLVCBrZXkgaGFzIEtWID0gMSAoU1BJKSBhbmQgVEdLIEtWID0gTlVM TCAobm90ZSB3ZSBjYW5ub3QgaGF2ZSBtdWx0aXBsZSBUR0tzIGluIHRoZSBzYW1lIE1JS0VZIG1l c3NhZ2Ugc2luY2UgTUtJIGlzIG5vdCBhbGxvd2VkIHdpdGggRUtUKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXQg ZG8geW91IChDaXNjbykgdGhpbms/IERvZXMgaXQgbWFrZSBzZW5zZSB0byB0cmFuc3BvcnQgYm90 aCBFS1Qga2V5IGFuZCBUR0sgaW4gTUlLRVkgb3IgZG8geW91IHByZWZlciB0byB1c2UgTUlLRVkg dG8gdHJhbnNwb3J0IEVLVCBrZXkgb25seT8gJm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5C ZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllpIENoZW5nPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5Fcmljc3NvbiBSZXNlYXJjaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4xNjQ4 MCBTdG9ja2hvbG08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U3dlZGVuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9D746FA33933A44198056E8E591AAB5B10554B6AESESSMB305erics_-- From nobody Mon Aug 11 01:52:19 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA991A038B for ; Mon, 11 Aug 2014 01:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 IH14onF5d1_J for ; Mon, 11 Aug 2014 01:52:14 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9AB1A0382 for ; Mon, 11 Aug 2014 01:52:12 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-00-53e8843a5d0b Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.59.24955.A3488E35; Mon, 11 Aug 2014 10:52:10 +0200 (CEST) Received: from ESESSMB305.ericsson.se ([169.254.5.45]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Mon, 11 Aug 2014 10:52:10 +0200 From: Yi Cheng To: "avt@ietf.org" Thread-Topic: Comments on SRTP EKT (cont'd) Thread-Index: Ac+1QVepxT8v8iv/T/eJElfTvujyZg== Date: Mon, 11 Aug 2014 08:52:09 +0000 Message-ID: <9D746FA33933A44198056E8E591AAB5B10554B82@ESESSMB305.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_9D746FA33933A44198056E8E591AAB5B10554B82ESESSMB305erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvja5Vy4tggxNLtSxe9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrULJ5kLTvxgrPhwroe1gbHlE2MXIyeHhICJxNO+YywQtpjE hXvr2boYuTiEBI4ySjQ9OMEC4SxmlGj/2cgOUsUmoCbx995rVhBbREBRovXaZ7BJwkDxd886 mCHi2hLPbt1hgbD1JP49eQ5WwyKgKjH/zV+wXl4BX4n2+cvBZjICbf5+ag0TiM0sIC5x68l8 JoiLBCSW7DnPDGGLSrx8/I8VwlaU+PhqHyNEfb7E16ez2CFmCkqcnPmEZQKj0Cwko2YhKZuF pGwWIwdQXFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2IULU4tTspNNzLWSy3KTC4uzs/T y0st2cQIjIuDW36r7mC8/MbxEKMAB6MSD+8C5RfBQqyJZcWVuYcYpTlYlMR5F56bFywkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBsS/NciPnmlteJvyOu93nPci4nLPTPvGRzeekNKvJrdzz bH4Yc/91tb+3c8H5u3MLb223T9mwzulcxbaTF5+wvlxQtD82dOaOhyzLuzctsU4Rj5+s++LK QTaNyKmPww4vm13edKrOTswh5tG6y95Lvhz/tHATS3LqkldTv9UvDvm0l3fH0rpysWwlluKM REMt5qLiRACkOhGCbAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avt/-GZFi2Yas9cx2eAxrDMOwAgsxI4 Subject: [AVTCORE] Comments on SRTP EKT (cont'd) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 08:52:16 -0000 --_000_9D746FA33933A44198056E8E591AAB5B10554B82ESESSMB305erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5vdGhlciBlbWFpbCB3aXRoIENpc2Nv4oCZcyByZXNwb25zZSBhbmQgRXJpY3Nzb27igJlzIGZ1 cnRoZXIgY29tbWVudHMNCg0KRnJvbTogWWkgQ2hlbmcNClNlbnQ6IGRlbiAxNSBtYWogMjAxNCAx MjoyNg0KVG86ICdEYW4gV2luZycNCkNjOiBGbGVtbWluZyBBbmRyZWFzb247IERhdmlkIE1jR3Jl dzsgTWFnbnVzIFdlc3Rlcmx1bmQ7IEpvaG4gTWF0dHNzb24NClN1YmplY3Q6IFJFOiBNSUtFWSBj b21tZW50cyBieSBGbGVtbWluZw0KDQoNCkhpIGFnYWluLA0KDQoNCg0KV2hlbiBhIE1JS0VZIHBl ZXIgdGhhdCBkb2VzIG5vdCB1bmRlcnN0YW5kIEVLVCByZWNlaXZlcyBhbiBTUlRQIHBvbGljeSBw YXlsb2FkIHdpdGggZXh0cmEgRUtUIHBhcmFtZXRlcnMsIGl0IHdpbGwgcmV0dXJuIGFuIGVycm9y IG1lc3NhZ2Ugd2l0aCBlcnJvciBuby4gMTAgKCBJbnZhbGlkIFNQIHBhcmFtZXRlcikuIFNpbmNl IHRoZSBwZWVyIHNhdyB0aGF0IHRoZSBpbnRlbmRlZCBzZWN1cml0eSBwcm90b2NvbCB3YXMgU1JU UCwgIGFjY29yZGluZyB0byBSRkMgMzgzMCBzZWN0aW9uIDUuMS4yDQoNCiJJZiB0aGUgUmVzcG9u ZGVyIGRvZXMgbm90IHN1cHBvcnQgdGhlIHNldCBvZiBwYXJhbWV0ZXJzIHN1Z2dlc3RlZCBieQ0K DQp0aGUgSW5pdGlhdG9yLCB0aGUgZXJyb3IgbWVzc2FnZSBTSE9VTEQgaW5jbHVkZSB0aGUgc3Vw cG9ydGVkDQoNCnBhcmFtZXRlcnMiLA0KDQppdCBzaG91bGQgaW5jbHVkZSBhbiBTUCBwYXlsb2Fk IGluIHRoZSBlcnJvciBtZXNzYWdlIHdpdGggbm9ybWFsIFNSVFAgcGFyYW1ldGVycy4gVGhlbiB0 aGUgaW5pdGlhdG9yIHdpbGwga25vdyB0aGF0IHRoZSBwZWVyIHN1cHBvcnRzIG9ubHkgU1JUUCBh bmQgcmUtaW5pdGlhdGUgTUlLRVkgYWNjb3JkaW5nbHkuDQoNCg0KDQpXZSB0aGluayB0aGlzIGlz IGJldHRlciB0aGFuIGludHJvZHVjaW5nIGEgbmV3IHNlY3VyaXR5IHByb3RvY29sIHR5cGUuIElu IHRoYXQgY2FzZSB0aGUgcGVlciB3aWxsIG9ubHkgc2VlIGFuIHVua25vd24gc2VjdXJpdHkgcHJv dG9jb2wgYW5kIGdldCBubyBoaW50IG9uIHdoYXQgdG8gcHJvcG9zZSBpbiB0aGUgZXJyb3IgbWVz c2FnZS4NCg0KDQoNCkFzIFJGQyA0NzcxIGFsc28gYWRkZWQgbmV3IFNSVFAgcGFyYW1ldGVycyB0 byBNSUtFWSwgd2UgaG9wZSBsZWdhY3kgTUlLRVkgaW1wbGVtZW50YXRpb25zIGNhbiBoYW5kbGUg dW5rbm93biBTUlRQIHBhcmFtZXRlcnMgaW4gYSBnb29kIHdheSA7LSkuDQoNCg0KDQpCZXN0IHJl Z2FyZHMsDQoNCllpDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGFu IFdpbmcgW21haWx0bzpkd2luZ0BjaXNjby5jb21dDQpTZW50OiBkZW4gMTQgbWFqIDIwMTQgMjE6 MTcNClRvOiBZaSBDaGVuZw0KQ2M6IEZsZW1taW5nIEFuZHJlYXNvbjsgRGF2aWQgTWNHcmV3OyBN YWdudXMgV2VzdGVybHVuZDsgSm9obiBNYXR0c3Nvbg0KU3ViamVjdDogUmU6IE1JS0VZIGNvbW1l bnRzIGJ5IEZsZW1taW5nDQoNCg0KDQoNCg0KT24gTWF5IDE0LCAyMDE0LCBhdCAxMjowMCBBTSwg WWkgQ2hlbmcgPHlpLmNoZW5nQGVyaWNzc29uLmNvbTxtYWlsdG86eWkuY2hlbmdAZXJpY3Nzb24u Y29tPj4gd3JvdGU6DQoNCg0KDQo+IEhpLA0KDQo+DQoNCj4gSm9obiBhbmQgbWUgaGF2ZSByZXZp ZXdlZCB0aGUgTUlLRVkgcGFydCBvZiB0aGUgRUtUIEludGVybmV0IERyYWZ0LiBXZSBzZWUgdGhl IGZvbGxvd2luZyBpc3N1ZXMgKEZsZW1taW5nIGhhcyBzaW1pbGFyIGNvbW1lbnRzIGluIEZTQSA0 OSwgRlNBIDUwIGFuZCBGU0EgNTQpOg0KDQo+IDEpICAgICAgU2VjdGlvbiA1IHNwZWNpZmllcyBv bmx5IGhvdyB0aGUgRUtUIHBhcmFtZXRlcnMgKGkuZS4gY2lwaGVyLCBrZXksIFNQSSkgYXJlIHRv IGJlIHRyYW5zcG9ydGVkIGluIHRoZSBNSUtFWSBtZXNzYWdlLiBIb3cgdGhlIFNSVFAgcGFyYW1l dGVycyBhcmUgbmVnb3RpYXRlZCBpcyBub3QgbWVudGlvbmVkLg0KDQo+IDIpICAgICAgQXMgY3Vy cmVudGx5IHNwZWNpZmllZCBpbiBzZWN0aW9uIDUuMSwgd2hlbiBFS1QgaXMgdXNlZCB0b2dldGhl ciB3aXRoIE1JS0VZLCB3ZSB3aWxsIGhhdmUgYSAgU2VjdXJpdHkgUG9saWN5IChTUCkgcGF5bG9h ZCB3aXRoIEVLVCBhcyB0aGUgUHJvdCB0eXBlIGFuZCBFS1QgY2lwaGVyIGFzIHRoZSBwYXJhbWV0 ZXIuIEJ1dCB3ZSBhbHNvIG5lZWQgYW5vdGhlciBTUCBwYXlsb2FkIHRvIGNvbW11bmljYXRlIFNS VFAgcGFyYW1ldGVycy4gV2hhdCBDUyBJRCBtYXAgaW5mbyBzaGFsbCBiZSBnaXZlbiBpbiB0aGUg Q29tbW9uIEhlYWRlciB0aGVuPyBJdOKAmXMgbm90IHBvc3NpYmxlIHRvIGhhdmUgdHdvIHBvbGlj aWVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2FtZSBDUy4NCg0KPg0KDQo+IE9uZSBwb3NzaWJsZSBz b2x1dGlvbiBpcyB0byBpbmNsdWRlIHRoZSBFS1QgY2lwaGVyIGFuZCBFS1QgU1BJIGluIHRoZSBT UlRQIHBvbGljeS4gU28gd2UgaGF2ZSBhIHNpbmdsZSBwb2xpY3kgd2l0aCBib3RoIFNSVFAgcGFy YW1ldGVycyBhbmQgRUtUIHBhcmFtZXRlcnMsIGF2b2lkaW5nIHRoZSBtYXBwaW5nIHByb2JsZW0g aW4gMikuIEVLVCBTUEkgY2FuIHRoZW4gYmUgdXNlZCB0byByZXRyaWV2ZSB0aGUgRUtUIHBhcmFt ZXRlciBzZXQsIGFzIHNwZWNpZmllZCBpbiBzZWN0aW9uIDIuMS4gSWYgd2UgZ28gZm9yIHRoaXMg d2UgbmVlZCB0byBhZGQgRUtUIFNQSSBhbmQgY2lwaGVyIHRvIHRoZSBTUlRQIHBvbGljeSBwYXJh bWV0ZXIgbGlzdCAoc2VjdGlvbiA2LjEwLjEgb2YgUkZDIDM4MzApIGFuZCByZW1vdmUgdGhlIEVL VCBzZWN1cml0eSBwb2xpY3kgYW5kIGNpcGhlciBwYXJhbWV0ZXIgZnJvbSBzZWN0aW9uIDUuMS4N Cg0KDQoNCkluIGFub3RoZXIgZW1haWwsIEZsZW1taW5nIHBvaW50ZWQgb3V0IHRoaXMgbmVlZHMg dG8gYmUgbmVnb3RpYWJsZSB3aXRoIGEgTUlLRVkgcGVlciB0aGF0IGRvZXMgbm90IHVuZGVyc3Rh bmQgRUtULg0KDQoNCg0KPiAgV2hhdCBkbyB5b3UgKENpc2NvKSB0aGluaz8gRG9lcyBpdCBtYWtl IHNlbnNlIHRvIHRyYW5zcG9ydCBib3RoIEVLVCBrZXkgYW5kIFRHSyBpbiBNSUtFWSBvciBkbyB5 b3UgcHJlZmVyIHRvIHVzZSBNSUtFWSB0byB0cmFuc3BvcnQgRUtUIGtleSBvbmx5Pw0KDQoNCg0K Tm9uZSBvZiB0aGUgdGhyZWUgb2YgdXMgdW5kZXJzdGFuZCBNSUtFWSB3ZWxsIGVub3VnaCB0byBh bnN3ZXIgdmVyeSBhdXRob3JpdGF0aXZlbHkuICBIb3dldmVyLCB3ZSBhZ3JlZSBmYXN0ZXIgY2Fs bCBzZXQtdXAgdGltZXMgYXJlIGRlc2lyYWJsZSwgd2hpY2ggYXMgeW91IG1lbnRpb24gYWJvdmUg aXMgYWNoaWV2ZWQgYnkgc2VuZGluZyBFS1Qga2V5IGFuZCBUR0sga2V5IGluIE1JS0VZLCByYXRo ZXIgdGhhbiB1c2luZyBNSUtFWSB0byB0cmFuc3BvcnQgb25seSB0aGUgRUtUIGtleS4NCg0KDQoN Ci1kDQoNCg0KDQoNCg0KPiBCZXN0IHJlZ2FyZHMsDQoNCj4gWWkgQ2hlbmcNCg0KPg0KDQo+IEVy aWNzc29uIFJlc2VhcmNoDQoNCj4gMTY0ODAgU3RvY2tob2xtDQoNCj4gU3dlZGVuDQoNCj4NCg0K PiBGcm9tOiBKb2huIE1hdHRzc29uDQoNCj4gU2VudDogZGVuIDUgbWFqIDIwMTQgMTM6NTUNCg0K PiBUbzogWWkgQ2hlbmcNCg0KPiBTdWJqZWN0OiBGVzogTUlLRVkgY29tbWVudHMgYnkgRmxlbW1p bmcNCg0KPg0KDQo+DQoNCj4NCg0KPiA8aW1hZ2UwMDEucG5nPg0KDQo+DQoNCj4gSk9ITiBNQVRU U1NPTg0KDQo+IE1TYyBFbmdpbmVlcmluZyBQaHlzaWNzLCBNU2MgQnVzaW5lc3MgQWRtaW5pc3Ry YXRpb24gYW5kIEVjb25vbWljcw0KDQo+IEVyaWNzc29uIElFVEYgU2VjdXJpdHkgQ29vcmRpbmF0 b3IgU2VuaW9yIFJlc2VhcmNoZXIsIFNlY3VyaXR5DQoNCj4NCg0KPiBFcmljc3NvbiBBQg0KDQo+ IFNlY3VyaXR5IFJlc2VhcmNoDQoNCj4gRsOkcsO2Z2F0YW4gNg0KDQo+IFNFLTE2NCA4MCBTdG9j a2hvbG0sIFN3ZWRlbg0KDQo+IFBob25lICs0NiAxMCA3MSA0MyA1MDENCg0KPiBTTVMvTU1TICs0 NiA3NiAxMSA1MyA1MDENCg0KPiBqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbTxtYWlsdG86am9o bi5tYXR0c3NvbkBlcmljc3Nvbi5jb20+DQoNCj4gd3d3LmVyaWNzc29uLmNvbTxodHRwOi8vd3d3 LmVyaWNzc29uLmNvbT4NCg0KPg0KDQo+DQoNCj4gPGltYWdlMDAyLnBuZz4NCg0KPg0KDQo+IFRo aXMgQ29tbXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2 ZSBlbWFpbCBvbg0KDQo+IHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdHd3dy5lcmlj c3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcg0KDQo+DQoNCj4NCg0KPiBGcm9tOiBEYW4gV2luZyA8 ZHdpbmdAY2lzY28uY29tPG1haWx0bzpkd2luZ0BjaXNjby5jb20+Pg0KDQo+IERhdGU6IEZyaWRh eSA0IEFwcmlsIDIwMTQgMjE6MjUNCg0KPiBUbzogSm9obiBNYXR0c3NvbiA8am9obi5tYXR0c3Nv bkBlcmljc3Nvbi5jb208bWFpbHRvOmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPj4NCg0KPiBD YzogTWFnbnVzIFdlc3Rlcmx1bmQgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTxtYWls dG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPj4NCg0KPiBTdWJqZWN0OiBSZTogTUlL RVkgY29tbWVudHMgYnkgRmxlbW1pbmcNCg0KPg0KDQo+DQoNCj4gT24gQXByIDQsIDIwMTQsIGF0 IDg6NDQgQU0sIERhbiBXaW5nIDxkd2luZ0BjaXNjby5jb208bWFpbHRvOmR3aW5nQGNpc2NvLmNv bT4+IHdyb3RlOg0KDQo+DQoNCj4NCg0KPg0KDQo+IE9uIEFwciA0LCAyMDE0LCBhdCA4OjA3IEFN LCBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbTxtYWlsdG86am9obi5t YXR0c3NvbkBlcmljc3Nvbi5jb20+PiB3cm90ZToNCg0KPg0KDQo+DQoNCj4gSGkgRGFuLA0KDQo+ DQoNCj4gTWFnbnVzIHByb21pc2VkIHRoYXQgT3NjYXIgT2hsc3NvbiBmcm9tIEVyaWNzc29uIHdv dWxkIHJldmlldyB0aGUgTUlLRVkgcGFydCBvZiBFS1QuIE9zY2FyIGhhcyBub3cgc3RvcHBlZCB3 b3JraW5nIHdpdGggc2VjdXJpdHkgc28gSSBsbCBkbyB0aGUgcmV2aWV3IGluc3RlYWQuIEluIHlv dXIgbWFpbCB0byBNYWdudXMgeW91IHNhaWQ6DQoNCj4NCg0KPiAiQ2FuIHRoZSBjaGFpcnMgc29s aWNpdCBhIGNvLWF1dGhvciBvciByZXZpZXdlciB3aG8gdW5kZXJzdGFuZHMgTUlLRVkgYW5kIGNh biBlbnN1cmUgdGhhdCBFS1QgYWNjdXJhdGVseSBkZXNjcmliZXMgRUtUJ3Mgb3BlcmF0aW9uIHdp dGggTUlLRVkuICBXZSBoYXZlIHNvbWUgY29tbWVudHMgYWdhaW5zdCB0aGUgTUlLRVkgc2VjdGlv biBieSBGbGVtbWluZyBidXQgdW5mb3J0dW5hdGVseSBhbGwgdGhyZWUgb2YgdXMgYXJlIG5vdCBm YW1pbGlhciBlbm91Z2ggd2l0aCBNSUtFWSB0byBzYXRpc2ZhY3RvcmlseSBjbG9zZSB0aG9zZSBj b21tZW50cy4iDQoNCj4NCg0KPiBUaGV5IHdlcmUgc2VudCB0byBtZSwgYXMgZWRpdG9yLiAgRmxl bW1pbmcgaXMgb25lIG9mIHRoZSBhdXRob3JzLCB3aGljaCBpcyB3aHkgaXQgZGlkbid0IGdldCBw b3N0ZWQgdG8gdGhlIGxpc3QuICBJJ2xsIGZpbmQgaXQgbGF0ZXIgdG9kYXkgYW5kIGVtYWlsIGl0 IHRvIHlvdS4NCg0KPg0KDQo+IEF0dGFjaGVkIGFyZSBGbGVtbWluZydzIGNvbW1lbnRzLiAgSSBj dXQgdGhlIHN0dWZmIGFib3ZlIGFuZCBiZWxvdyB0aGUgTUlLRVkgc2VjdGlvbiwgc28geW91IGNh biBzaW1wbHkgcHJpbnQgb3IgcmV2aWV3IHRoZSBhdHRhY2hlZC4gIEkgY3V0IHVzaW5nIFRyYWNr IENoYW5nZXMsIHNvIGlmIHlvdSB3YW50ZWQgdG8gc2VlIEZsZW1taW5nJ3Mgb3RoZXIgY29tbWVu dHMgZm9yIGNvbnRleHQgeW91IGNhbiBzdGlsbCBzZWUgdGhlbS4NCg0KPg0KDQo+IC1kDQoNCj4N Cg0KPg0KDQo+IC1kDQoNCj4NCg0KPg0KDQo+DQoNCj4gSSBjYW5ub3QgZmluZCB0aGVzZSBjb21t ZW50cyBieSBGbGVtbWluZy4gV2VyZSB0aGV5IHNlbmQgaW4gcHJpdmF0ZSBvciBvbiBzb21lIG90 aGVyIGxpc3QgdGhhbiBBVlRDT1JFPw0KDQo+DQoNCj4gQ2hlZXJzIEpvaG4NCg0KPg0KDQo+DQoN Cj4gPDEzREVGQjk0LUY3MzUtNDlCMC04MTk2LUJEQjVDOTAxN0EzMls0XS5wbmc+DQoNCj4NCg0K PiBKT0hOIE1BVFRTU09ODQoNCj4gTVNjIEVuZ2luZWVyaW5nIFBoeXNpY3MsIE1TYyBCdXNpbmVz cyBBZG1pbmlzdHJhdGlvbiBhbmQgRWNvbm9taWNzDQoNCj4gRXJpY3Nzb24gSUVURiBTZWN1cml0 eSBDb29yZGluYXRvciBTZW5pb3IgUmVzZWFyY2hlciwgU2VjdXJpdHkNCg0KPg0KDQo+IEVyaWNz c29uIEFCDQoNCj4gU2VjdXJpdHkgUmVzZWFyY2gNCg0KPiBGw6Ryw7ZnYXRhbiA2DQoNCj4gU0Ut MTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuDQoNCj4gUGhvbmUgKzQ2IDEwIDcxIDQzIDUwMQ0KDQo+ IFNNUy9NTVMgKzQ2IDc2IDExIDUzIDUwMQ0KDQo+IGpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29t PG1haWx0bzpqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4NCg0KPiB3d3cuZXJpY3Nzb24uY29t PGh0dHA6Ly93d3cuZXJpY3Nzb24uY29tPg0KDQo+DQoNCj4NCg0KPiA8RDM3N0U4MDAtMEExQS00 M0QzLUFGNUUtMTY1RjY5Nzc4OUI1WzRdLnBuZz4NCg0KPg0KDQo+IFRoaXMgQ29tbXVuaWNhdGlv biBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbg0KDQo+ IHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdHd3dy5lcmljc3Nvbi5jb20vZW1haWxf ZGlzY2xhaW1lcg0KDQoNCg== --_000_9D746FA33933A44198056E8E591AAB5B10554B82ESESSMB305erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRl eHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0 IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0Fj ZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs bG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFub3RoZXIgZW1haWwgd2l0aCBDaXNj b+KAmXMgcmVzcG9uc2UgYW5kIEVyaWNzc29u4oCZcyBmdXJ0aGVyIGNvbW1lbnRzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gWWkg Q2hlbmcNCjxicj4NCjxiPlNlbnQ6PC9iPiBkZW4gMTUgbWFqIDIwMTQgMTI6MjY8YnI+DQo8Yj5U bzo8L2I+ICdEYW4gV2luZyc8YnI+DQo8Yj5DYzo8L2I+IEZsZW1taW5nIEFuZHJlYXNvbjsgRGF2 aWQgTWNHcmV3OyBNYWdudXMgV2VzdGVybHVuZDsgSm9obiBNYXR0c3Nvbjxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSRTogTUlLRVkgY29tbWVudHMgYnkgRmxlbW1pbmc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IaSBhZ2Fpbiw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+V2hlbiBhIE1JS0VZIHBlZXIgdGhhdCBkb2VzIG5vdCB1bmRlcnN0YW5k IEVLVCByZWNlaXZlcyBhbiBTUlRQIHBvbGljeSBwYXlsb2FkIHdpdGggZXh0cmEgRUtUIHBhcmFt ZXRlcnMsIGl0IHdpbGwgcmV0dXJuIGFuIGVycm9yIG1lc3NhZ2Ugd2l0aCBlcnJvciBuby4gMTAg KCBJbnZhbGlkIFNQIHBhcmFtZXRlcikuIFNpbmNlIHRoZSBwZWVyIHNhdyB0aGF0IHRoZSBpbnRl bmRlZCBzZWN1cml0eSBwcm90b2NvbA0KIHdhcyBTUlRQLCAmbmJzcDthY2NvcmRpbmcgdG8gUkZD IDM4MzAgc2VjdGlvbiA1LjEuMjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+JnF1b3Q7PGk+SWYgdGhlIFJlc3BvbmRlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSBzZXQgb2Yg cGFyYW1ldGVycyBzdWdnZXN0ZWQgYnk8bzpwPjwvbzpwPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48aT50aGUgSW5pdGlhdG9yLCB0aGUgZXJyb3IgbWVzc2FnZSBTSE9VTEQgaW5j bHVkZSB0aGUgc3VwcG9ydGVkPG86cD48L286cD48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PGk+cGFyYW1ldGVyczwvaT4mcXVvdDssPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5pdCBzaG91bGQgaW5jbHVkZSBhbiBTUCBwYXlsb2FkIGluIHRoZSBlcnJv ciBtZXNzYWdlIHdpdGggbm9ybWFsIFNSVFAgcGFyYW1ldGVycy4gVGhlbiB0aGUgaW5pdGlhdG9y IHdpbGwga25vdyB0aGF0IHRoZSBwZWVyIHN1cHBvcnRzIG9ubHkgU1JUUCBhbmQgcmUtaW5pdGlh dGUgTUlLRVkgYWNjb3JkaW5nbHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldlIHRo aW5rIHRoaXMgaXMgYmV0dGVyIHRoYW4gaW50cm9kdWNpbmcgYSBuZXcgc2VjdXJpdHkgcHJvdG9j b2wgdHlwZS4gSW4gdGhhdCBjYXNlIHRoZSBwZWVyIHdpbGwgb25seSBzZWUgYW4gdW5rbm93biBz ZWN1cml0eSBwcm90b2NvbCBhbmQgZ2V0IG5vIGhpbnQgb24gd2hhdCB0byBwcm9wb3NlIGluIHRo ZSBlcnJvciBtZXNzYWdlLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFzIFJGQyA0 NzcxIGFsc28gYWRkZWQgbmV3IFNSVFAgcGFyYW1ldGVycyB0byBNSUtFWSwgd2UgaG9wZSBsZWdh Y3kgTUlLRVkgaW1wbGVtZW50YXRpb25zIGNhbiBoYW5kbGUgdW5rbm93biBTUlRQIHBhcmFtZXRl cnMgaW4gYSBnb29kIHdheSA7LSkuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QmVz dCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+WWk8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ DQpGcm9tOiBEYW4gV2luZyBbPGEgaHJlZj0ibWFpbHRvOmR3aW5nQGNpc2NvLmNvbSI+bWFpbHRv OmR3aW5nQGNpc2NvLmNvbTwvYT5dIDxicj4NClNlbnQ6IGRlbiAxNCBtYWogMjAxNCAyMToxNzxi cj4NClRvOiBZaSBDaGVuZzxicj4NCkNjOiBGbGVtbWluZyBBbmRyZWFzb247IERhdmlkIE1jR3Jl dzsgTWFnbnVzIFdlc3Rlcmx1bmQ7IEpvaG4gTWF0dHNzb248YnI+DQpTdWJqZWN0OiBSZTogTUlL RVkgY29tbWVudHMgYnkgRmxlbW1pbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5PbiBNYXkgMTQsIDIw MTQsIGF0IDEyOjAwIEFNLCBZaSBDaGVuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlpLmNoZW5nQGVy aWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPnlpLmNoZW5nQGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBIaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IEpvaG4gYW5kIG1lIGhhdmUgcmV2aWV3ZWQgdGhlIE1JS0VZIHBhcnQg b2YgdGhlIEVLVCBJbnRlcm5ldCBEcmFmdC4gV2Ugc2VlIHRoZSBmb2xsb3dpbmcgaXNzdWVzIChG bGVtbWluZyBoYXMgc2ltaWxhciBjb21tZW50cyBpbiBGU0EgNDksIEZTQSA1MCBhbmQgRlNBIDU0 KTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgMSkmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VjdGlvbiA1IHNwZWNpZmllcyBvbmx5IGhvdyB0aGUg RUtUIHBhcmFtZXRlcnMgKGkuZS4gY2lwaGVyLCBrZXksIFNQSSkgYXJlIHRvIGJlIHRyYW5zcG9y dGVkIGluIHRoZSBNSUtFWSBtZXNzYWdlLiBIb3cgdGhlIFNSVFAgcGFyYW1ldGVycyBhcmUgbmVn b3RpYXRlZCBpcyBub3QgbWVudGlvbmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAyKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBcyBjdXJyZW50 bHkgc3BlY2lmaWVkIGluIHNlY3Rpb24gNS4xLCB3aGVuIEVLVCBpcyB1c2VkIHRvZ2V0aGVyIHdp dGggTUlLRVksIHdlIHdpbGwgaGF2ZSBhJm5ic3A7IFNlY3VyaXR5IFBvbGljeSAoU1ApIHBheWxv YWQgd2l0aCBFS1QgYXMgdGhlIFByb3QgdHlwZSBhbmQgRUtUIGNpcGhlciBhcyB0aGUgcGFyYW1l dGVyLiBCdXQgd2UgYWxzbyBuZWVkIGFub3RoZXIgU1AgcGF5bG9hZCB0byBjb21tdW5pY2F0ZQ0K IFNSVFAgcGFyYW1ldGVycy4gV2hhdCBDUyBJRCBtYXAgaW5mbyBzaGFsbCBiZSBnaXZlbiBpbiB0 aGUgQ29tbW9uIEhlYWRlciB0aGVuPyBJdOKAmXMgbm90IHBvc3NpYmxlIHRvIGhhdmUgdHdvIHBv bGljaWVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2FtZSBDUy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IE9uZSBwb3NzaWJsZSBzb2x1dGlvbiBpcyB0byBpbmNsdWRlIHRo ZSBFS1QgY2lwaGVyIGFuZCBFS1QgU1BJIGluIHRoZSBTUlRQIHBvbGljeS4gU28gd2UgaGF2ZSBh IHNpbmdsZSBwb2xpY3kgd2l0aCBib3RoIFNSVFAgcGFyYW1ldGVycyBhbmQgRUtUIHBhcmFtZXRl cnMsIGF2b2lkaW5nIHRoZSBtYXBwaW5nIHByb2JsZW0gaW4gMikuIEVLVCBTUEkgY2FuIHRoZW4g YmUgdXNlZCB0byByZXRyaWV2ZSB0aGUNCiBFS1QgcGFyYW1ldGVyIHNldCwgYXMgc3BlY2lmaWVk IGluIHNlY3Rpb24gMi4xLiBJZiB3ZSBnbyBmb3IgdGhpcyB3ZSBuZWVkIHRvIGFkZCBFS1QgU1BJ IGFuZCBjaXBoZXIgdG8gdGhlIFNSVFAgcG9saWN5IHBhcmFtZXRlciBsaXN0IChzZWN0aW9uIDYu MTAuMSBvZiBSRkMgMzgzMCkgYW5kIHJlbW92ZSB0aGUgRUtUIHNlY3VyaXR5IHBvbGljeSBhbmQg Y2lwaGVyIHBhcmFtZXRlciBmcm9tIHNlY3Rpb24gNS4xLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5JbiBhbm90aGVyIGVtYWlsLCBGbGVtbWluZyBwb2ludGVkIG91dCB0aGlzIG5lZWRz IHRvIGJlIG5lZ290aWFibGUgd2l0aCBhIE1JS0VZIHBlZXIgdGhhdCBkb2VzIG5vdCB1bmRlcnN0 YW5kIEVLVC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyBXaGF0IGRv IHlvdSAoQ2lzY28pIHRoaW5rPyBEb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gdHJhbnNwb3J0IGJvdGgg RUtUIGtleSBhbmQgVEdLIGluIE1JS0VZIG9yIGRvIHlvdSBwcmVmZXIgdG8gdXNlIE1JS0VZIHRv IHRyYW5zcG9ydCBFS1Qga2V5IG9ubHk/Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Tm9uZSBvZiB0aGUgdGhyZWUgb2YgdXMgdW5kZXJzdGFuZCBNSUtF WSB3ZWxsIGVub3VnaCB0byBhbnN3ZXIgdmVyeSBhdXRob3JpdGF0aXZlbHkuJm5ic3A7IEhvd2V2 ZXIsIHdlIGFncmVlIGZhc3RlciBjYWxsIHNldC11cCB0aW1lcyBhcmUgZGVzaXJhYmxlLCB3aGlj aCBhcyB5b3UgbWVudGlvbiBhYm92ZSBpcyBhY2hpZXZlZCBieSBzZW5kaW5nIEVLVCBrZXkgYW5k IFRHSyBrZXkgaW4gTUlLRVksIHJhdGhlciB0aGFuDQogdXNpbmcgTUlLRVkgdG8gdHJhbnNwb3J0 IG9ubHkgdGhlIEVLVCBrZXkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi1kPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBCZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFlpIENoZW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBFcmljc3NvbiBSZXNlYXJjaDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAxNjQ4MCBTdG9ja2hvbG08bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgU3dlZGVuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBGcm9tOiBKb2huIE1hdHRzc29uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFNlbnQ6IGRlbiA1IG1haiAyMDE0IDEzOjU1PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRvOiBZaSBDaGVuZzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTdWJqZWN0OiBGVzogTUlLRVkg Y29tbWVudHMgYnkgRmxlbW1pbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZu YnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmx0O2lt YWdlMDAxLnBuZyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEpPSE4gTUFU VFNTT048bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgTVNjIEVu Z2luZWVyaW5nIFBoeXNpY3MsIE1TYyBCdXNpbmVzcyBBZG1pbmlzdHJhdGlvbiBhbmQgRWNvbm9t aWNzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRXJpY3Nz b24gSUVURiBTZWN1cml0eSBDb29yZGluYXRvciBTZW5pb3IgUmVzZWFyY2hlciwgU2VjdXJpdHk8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEVyaWNzc29uIEFCPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFNlY3VyaXR5IFJlc2VhcmNoPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEbDpHLDtmdhdGFuIDY8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgU0UtMTY0IDgwIFN0b2Nr aG9sbSwgU3dlZGVuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IFBob25lICYjNDM7NDYgMTAgNzEgNDMgNTAxPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IFNNUy9NTVMgJiM0Mzs0NiA3NiAxMSA1MyA1MDE8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPGEgaHJlZj0ibWFpbHRvOmpvaG4ubWF0 dHNzb25AZXJpY3Nzb24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb208L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8YSBocmVmPSJodHRwOi8v d3d3LmVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPnd3dy5lcmljc3Nvbi5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZsdDtpbWFnZTAwMi5wbmcmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBUaGlzIENvbW11bmljYXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNl bmQgYW5kIHJlY2VpdmUgZW1haWwgb24NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXR3d3cuZXJpY3Nz b24uY29tL2VtYWlsX2Rpc2NsYWltZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBGcm9tOiBEYW4gV2luZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmR3aW5nQGNpc2NvLmNvbSI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmR3aW5nQGNp c2NvLmNvbTwvc3Bhbj48L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBEYXRlOiBGcmlkYXkgNCBBcHJpbCAyMDE0IDIxOjI1PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRvOiBKb2huIE1hdHRzc29uICZsdDs8YSBo cmVmPSJtYWlsdG86am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5qb2huLm1hdHRzc29uQGVyaWNzc29u LmNvbTwvc3Bhbj48L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBDYzogTWFnbnVzIFdlc3Rlcmx1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYWdudXMu d2VzdGVybHVuZEBlcmljc3Nvbi5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5tYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208L3NwYW4+ PC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgU3Vi amVjdDogUmU6IE1JS0VZIGNvbW1lbnRzIGJ5IEZsZW1taW5nPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgT24gQXByIDQsIDIwMTQsIGF0IDg6NDQgQU0sIERhbiBXaW5nICZsdDs8 YSBocmVmPSJtYWlsdG86ZHdpbmdAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ZHdpbmdAY2lzY28uY29tPC9zcGFuPjwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBPbiBBcHIgNCwgMjAxNCwgYXQgODowNyBBTSwgSm9o biBNYXR0c3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29t Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+am9o bi5tYXR0c3NvbkBlcmljc3Nvbi5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgSGkgRGFuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgTWFnbnVzIHByb21pc2VkIHRoYXQgT3NjYXIgT2hsc3NvbiBmcm9tIEVyaWNzc29uIHdvdWxk IHJldmlldyB0aGUgTUlLRVkgcGFydCBvZiBFS1QuIE9zY2FyIGhhcyBub3cgc3RvcHBlZCB3b3Jr aW5nIHdpdGggc2VjdXJpdHkgc28gSSBsbCBkbyB0aGUgcmV2aWV3IGluc3RlYWQuIEluIHlvdXIg bWFpbCB0byBNYWdudXMgeW91IHNhaWQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmcXVvdDtDYW4gdGhlIGNoYWlycyBzb2xpY2l0IGEgY28tYXV0aG9yIG9yIHJldmll d2VyIHdobyB1bmRlcnN0YW5kcyBNSUtFWSBhbmQgY2FuIGVuc3VyZSB0aGF0IEVLVCBhY2N1cmF0 ZWx5IGRlc2NyaWJlcyBFS1QncyBvcGVyYXRpb24gd2l0aCBNSUtFWS4mbmJzcDsgV2UgaGF2ZSBz b21lIGNvbW1lbnRzIGFnYWluc3QgdGhlIE1JS0VZIHNlY3Rpb24gYnkgRmxlbW1pbmcgYnV0IHVu Zm9ydHVuYXRlbHkgYWxsIHRocmVlDQogb2YgdXMgYXJlIG5vdCBmYW1pbGlhciBlbm91Z2ggd2l0 aCBNSUtFWSB0byBzYXRpc2ZhY3RvcmlseSBjbG9zZSB0aG9zZSBjb21tZW50cy4mcXVvdDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsgPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRoZXkgd2VyZSBzZW50IHRvIG1l LCBhcyBlZGl0b3IuJm5ic3A7IEZsZW1taW5nIGlzIG9uZSBvZiB0aGUgYXV0aG9ycywgd2hpY2gg aXMgd2h5IGl0IGRpZG4ndCBnZXQgcG9zdGVkIHRvIHRoZSBsaXN0LiZuYnNwOyBJJ2xsIGZpbmQg aXQgbGF0ZXIgdG9kYXkgYW5kIGVtYWlsIGl0IHRvIHlvdS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IEF0dGFjaGVkIGFyZSBGbGVtbWluZydzIGNvbW1lbnRzLiZuYnNw OyBJIGN1dCB0aGUgc3R1ZmYgYWJvdmUgYW5kIGJlbG93IHRoZSBNSUtFWSBzZWN0aW9uLCBzbyB5 b3UgY2FuIHNpbXBseSBwcmludCBvciByZXZpZXcgdGhlIGF0dGFjaGVkLiZuYnNwOyBJIGN1dCB1 c2luZyBUcmFjayBDaGFuZ2VzLCBzbyBpZiB5b3Ugd2FudGVkIHRvIHNlZSBGbGVtbWluZydzIG90 aGVyIGNvbW1lbnRzIGZvciBjb250ZXh0IHlvdSBjYW4NCiBzdGlsbCBzZWUgdGhlbS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsgPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IC1kPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgLWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsg PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgSSBjYW5ub3QgZmluZCB0aGVzZSBjb21tZW50cyBieSBG bGVtbWluZy4gV2VyZSB0aGV5IHNlbmQgaW4gcHJpdmF0ZSBvciBvbiBzb21lIG90aGVyIGxpc3Qg dGhhbiBBVlRDT1JFPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ2hl ZXJzIEpvaG48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJz cDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7IDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbHQ7MTNERUZCOTQt RjczNS00OUIwLTgxOTYtQkRCNUM5MDE3QTMyWzRdLnBuZyZndDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IEpPSE4gTUFUVFNTT048bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgTVNjIEVuZ2luZWVyaW5nIFBoeXNpY3MsIE1TYyBCdXNpbmVzcyBB ZG1pbmlzdHJhdGlvbiBhbmQgRWNvbm9taWNzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgRXJpY3Nzb24gSUVURiBTZWN1cml0eSBDb29yZGluYXRvciBTZW5p b3IgUmVzZWFyY2hlciwgU2VjdXJpdHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IEVyaWNzc29uIEFCPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IFNlY3VyaXR5IFJlc2VhcmNoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IEbDpHLDtmdhdGFuIDY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFBob25lICYjNDM7NDYgMTAgNzEgNDMgNTAxPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFNNUy9NTVMgJiM0Mzs0NiA3 NiAxMSA1MyA1MDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg PGEgaHJlZj0ibWFpbHRvOmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+am9obi5tYXR0c3NvbkBlcmlj c3Nvbi5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnd3dy5lcmljc3Nvbi5jb208L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZsdDtEMzc3RTgwMC0wQTFBLTQzRDMtQUY1 RS0xNjVGNjk3Nzg5QjVbNF0ucG5nJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgVGhpcyBDb21tdW5pY2F0aW9uIGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5k IGFuZCByZWNlaXZlIGVtYWlsIG9uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0d3d3LmVyaWNzc29u LmNvbS9lbWFpbF9kaXNjbGFpbWVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9D746FA33933A44198056E8E591AAB5B10554B82ESESSMB305erics_-- From nobody Mon Aug 11 02:43:51 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAC71A03AA for ; Mon, 11 Aug 2014 02:43:50 -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 xvgSfOELsTvJ for ; Mon, 11 Aug 2014 02:43: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 3B30D1A03A4 for ; Mon, 11 Aug 2014 02:43:49 -0700 (PDT) Received: from [79.78.95.247] (port=50379 helo=[192.168.0.8]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XGm8l-0003Uk-BE; Mon, 11 Aug 2014 10:43: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: Mon, 11 Aug 2014 10:43:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <34F4D145-3592-484E-A1A9-878E0D62A88B@csperkins.org> References: <3147A00C-8D9D-41FD-8A4B-273972E769B0@csperkins.org> <25F74D0B-5BB2-480F-B4FA-10D226843952@csperkins.org> <716C6558-C1B9-499E-A0A2-93F9111802AA@csperkins.org> To: Stephan Wenger 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/avt/AXeiJ8u6PGjstlyPqdEazdpoE3Q Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Topologies-update, reply to Bo's review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 09:43:51 -0000 Hi Stephan, [inline] On 8 Aug 2014, at 18:45, Stephan Wenger wrote: > Hi Colin, > I think I start seeing your point. Let me work on section 3.10 a bit = more > (over the weekend most likely). > But please also see inline (towards the top of the thread only). > Thanks, > Stephan >=20 >=20 > On 8/8/14, 10:22 AM, "Colin Perkins" wrote: >=20 >> Hi, >>=20 >> On 8 Aug 2014, at 16:20, Stephan Wenger wrote: >>> On 8/8/14, 7:36 AM, "Colin Perkins" wrote: >>>> They=B9re logically part of the same endpoint, and use a common = clock, >>>> and >>>> this makes them semantically coupled anyway, so I think a common = CNAME >>>> and single RTP session makes sense (this is essentially the design = the >>>> old Mbone tools used to lip-sync when audio and video were done = with >>>> separate tools, using a coordination protocol). >>>=20 >>> So let=B9s assume a common CNAME, but also separate transport = addresses >>> per subunit. Both version 02 and 03 of the draft comment on that = scenario >>> as follows: >>>=20 >>> =B3It is not really feasible to decompose one logical end-point into = two >>> different transport nodes in one RTP session. >=20 > This is the statement you question. You argue it is possible and = still > stay compliant with RTP. >=20 >>> A third party monitor would report such an attempt as two entities = being two different end-points with a CNAME collision. >=20 > Do I understand you correctly that yes, a third party monitor would = indeed > report a CNAME collision, but that=B9s a problem of the third party = monitor. Correct. A =93CNAME collision=94 is not a problem in RTP. Two SSRCs = sending media with the same CNAME from different source address/port = pairs is perfectly legal. > Or, better, the third party monitor=B9s lack of awareness of the = existence > of decomposed endpoint subunits in the same RTP session, them being a > legal (and, in at least some scenarios, even desirable) design choice. Right. This can also occur with multi-homed endpoints, sending media = using multiple interfaces.=20 >>> As a result, a fully RTP conformant de-composited >>> endpoint is one where the different decomposed parts use separate = RTP >>> sessions to send and/or receive media streams intended for them." >=20 > And this is, according to you, an incorrect statement. No. The RTP streams generated by a decomposed endpoint can from a single = RTP session, or they can form multiple RTP sessions. Whether they do so = or not depends on SSRC visibility, and is orthogonal to the choice of = CNAME (since they=92ll always use a single CNAME) or the number of = transport layer flows. Cheers, Colin From nobody Wed Aug 13 08:14:16 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B841A0A8D; Tue, 12 Aug 2014 16:56:54 -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 mmvFOxsHpewP; Tue, 12 Aug 2014 16:56:52 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C8D1A079F; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id nu7so7848740obb.0 for ; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TvOMDq5bVsm7hrc0pMtqzJ3nCKU6PoaHcLOkO23aYxw=; b=Q2edh9KLW9eYpiJj7ynYizJxi2kDLXhA+WMrRGDFSwuWjFjw6l7ID0T4Cg4ifLYflI 9krQwPRmtajzhKepJRPiSlzdXx726KuTAfhsHatbGMn2PfyKAhIOjoWJ27DuD5y/A53P PbBoP81QEVdyfvvvWR+QdV0mYtj+A0i99lN7eVoE+OCrf6UcJ3EuE1I5sJw/CxQVrurK gV3yjCrAWpFCOV+tm+2rpCZZpgVDtgUDTu1gC4rdWCmoxN0AKcgu1WZGgiZm1gEsMV37 1KinnXCsG9qOV6vcurtE3jA6biqj7Ww9hH7tH+XHpMIS5p83eAeiKksRp4xThpJgT3y9 f1VQ== MIME-Version: 1.0 X-Received: by 10.60.74.104 with SMTP id s8mr1039793oev.5.1407887811135; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) In-Reply-To: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> References: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> Date: Tue, 12 Aug 2014 16:56:51 -0700 Message-ID: From: Dave Taht To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/avt/xejn-9gKoJouadh8ZOEFKd-dHXs X-Mailman-Approved-At: Wed, 13 Aug 2014 08:14:13 -0700 Cc: mmusic@ietf.org, draft-ietf-dart-dscp-rtp.all@tools.ietf.org, "clue@ietf.org" , avt@ietf.org, "rmcat@ietf.org" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [AVTCORE] [rtcweb] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 23:56:54 -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... On Sat, Aug 9, 2014 at 11:48 AM, Ben Campbell wrote: > Hi, > > The DART working group has started a last call for draft-ietf-dart-dscp-r= tp-02, ending on August 22. This informational draft describes consideratio= ns for the use of DiffServ code points in situations where one multiplexes = multiple RTP packet streams, and potentially other protocol streams, that s= hare 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, MM= USIC, CLUE, RTCWEB, and RMCAT. Please send any feedback (including feedback= to the effect of "this is ready to progress") to the DART working group ma= iling 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, Ric= hard Barnes >> >> This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. I= t'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. >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Mon Aug 18 08:17:54 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/_J8TuLpl9Z1IvNtsfhxsshHAYhI Cc: "avt@ietf.org WG" , draft-ietf-dart-dscp-rtp.all@tools.ietf.org Subject: Re: [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:40 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/bC9-FHx-NZz9sSkhM8TofeEL79E Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, dart@ietf.org, "avt@ietf.org WG" Subject: Re: [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 23:50:30 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811DF1A883E; Mon, 18 Aug 2014 23:50:28 -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 xODr43kMcdmJ; Mon, 18 Aug 2014 23:50:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9388D1A6F3E; Mon, 18 Aug 2014 23:50:27 -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: <20140819065027.14670.39691.idtracker@ietfa.amsl.com> Date: Mon, 18 Aug 2014 23:50:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/mXY-Sz7a2iOENi8jCDpJyLIJ_Jk Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-topologies-update-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 06:50:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : RTP Topologies Authors : Magnus Westerlund Stephan Wenger Filename : draft-ietf-avtcore-rtp-topologies-update-04.txt Pages : 45 Date : 2014-08-18 Abstract: This document discusses point to point and multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This document is updated with additional topologies and is intended to replace RFC 5117. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-topologies-update/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-topologies-update-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 18 23:53:57 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519AD1A6F3C for ; Mon, 18 Aug 2014 23:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 XyrB2xxgdy6d for ; Mon, 18 Aug 2014 23:53:53 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3FDE1A02FE for ; Mon, 18 Aug 2014 23:53:53 -0700 (PDT) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB362.namprd07.prod.outlook.com (10.141.75.21) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Tue, 19 Aug 2014 06:53:42 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.237]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.237]) with mapi id 15.00.1005.008; Tue, 19 Aug 2014 06:53:42 +0000 From: Stephan Wenger To: "avt@ietf.org" Thread-Topic: RTP topologies update -04 posted Thread-Index: AQHPu3pPCmjEwZp+60W3uQauEYbOmw== Date: Tue, 19 Aug 2014 06:53:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.42.32.55] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0308EE423E x-forefront-antispam-report: SFV:NSPM; SFS:(10019006)(6009001)(189002)(199003)(164054003)(43784003)(110136001)(106116001)(95666004)(107886001)(105586002)(66066001)(80022001)(99286002)(83322001)(81342001)(107046002)(101416001)(106356001)(64706001)(20776003)(16236675004)(31966008)(2351001)(36756003)(21056001)(92566001)(79102001)(99396002)(85306004)(86362001)(92726001)(77982001)(76482001)(2656002)(87936001)(46102001)(54356999)(83072002)(85852003)(50986999)(74502001)(229853001)(77096002)(4396001)(74662001)(81542001)(2501001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR07MB362; H:CO1PR07MB363.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: multipart/alternative; boundary="_000_D018427D461C1stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/avt/_8GJMHS8WPmlJp-_LsfhD__DYbs Subject: [AVTCORE] RTP topologies update -04 posted X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 06:53:55 -0000 --_000_D018427D461C1stewesteweorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I just posted version 4 of the RTP topologies update I-D. The only technic= al changes are in section 3.10 on the subject of split component terminals,= as per discussions on this list over the last two weeks, as well as privat= e conversations I had with Colin Perkins afterwards. Thanks again to Colin= for his careful review and guidance. Please review. Thanks, Stephan --_000_D018427D461C1stewesteweorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <6F7D996F4C5764438B66F96D9493B87A@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,
I just posted version 4 of the RTP topologies update I-D.  The on= ly technical changes are in section 3.10 on the subject of split component = terminals, as per discussions on this list over the last two weeks, as well= as private conversations I had with Colin Perkins afterwards.  Thanks again to Colin for his careful revi= ew and guidance.
Please review.
Thanks,
Stephan


--_000_D018427D461C1stewesteweorg_-- From nobody Fri Aug 22 08:40:57 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/EkSbal5ZLKhVIaut7d6eUqAV34Q X-Mailman-Approved-At: Fri, 22 Aug 2014 08:40:55 -0700 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 14:24:52 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/IsSvrBkWoWVYkh2h572kxQoUP0U Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , Colin Perkins , "avt@ietf.org WG" Subject: Re: [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 - proposed text for section 2.1 mux items 3 and 4 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 Sat Aug 23 09:09:06 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/rtEQ4d49R7ZpSAGVzSATExWFYK8 X-Mailman-Approved-At: Sat, 23 Aug 2014 09:08:55 -0700 Cc: "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: [AVTCORE] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 Sat Aug 23 09:09:13 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/0K02DZQ58bYni_e6UFennPs93jM X-Mailman-Approved-At: Sat, 23 Aug 2014 09:08:56 -0700 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 - proposed text for section 2.1 mux items 3 and 4 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 Sat Aug 23 09:09:14 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/1PNbMyyAM-lbo9CsjHRv_EptxyU X-Mailman-Approved-At: Sat, 23 Aug 2014 09:08:59 -0700 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , Colin Perkins , "avt@ietf.org WG" Subject: Re: [AVTCORE] WGLC: draft-ietf-dart-dscp-rtp-02 - proposed text for section 2.1 mux items 3 and 4 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 Mon Aug 25 04:20:04 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/4JQ8nYt7ZxfOMFPEN8pHU50JJC8 Cc: "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [AVTCORE] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 08:39:33 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA951A0033; Mon, 25 Aug 2014 08:39:28 -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 0Ws2oC7FOd2P; Mon, 25 Aug 2014 08:39:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 588891A002D; Mon, 25 Aug 2014 08:39:12 -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: <20140825153912.28368.82143.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 08:39:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/SWMEIqR9KC3lhLTbnZggmiWu2nk Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-multi-stream-optimisation-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 15:39:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback Authors : Jonathan Lennox Magnus Westerlund Qin Wu Colin Perkins Filename : draft-ietf-avtcore-rtp-multi-stream-optimisation-04.txt Pages : 17 Date : 2014-08-25 Abstract: RTP allows multiple media streams to be sent in a single session, but requires each Synchronisation Source (SSRC) to send RTCP reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream-optimisation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-multi-stream-optimisation-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-multi-stream-optimisation-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 08:46:22 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599331A0081 for ; Mon, 25 Aug 2014 08:46:20 -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 swImcJ7cqJwG for ; Mon, 25 Aug 2014 08:46:17 -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 E7A501A001C for ; Mon, 25 Aug 2014 08:45:36 -0700 (PDT) Received: from [130.209.247.112] (port=62431 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 1XLwSd-0005Dt-2J for avt@ietf.org; Mon, 25 Aug 2014 16:45:35 +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: <20140825153912.28368.82143.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 16:45:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0453703C-BEB7-4CE6-AD4C-447A6FC61350@csperkins.org> References: <20140825153912.28368.82143.idtracker@ietfa.amsl.com> To: "avt@ietf.org WG" 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/avt/LQoe-oQ67_yckCvu48lZbYTmYso Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-multi-stream-optimisation-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 15:46:20 -0000 This is a minor update, to address Paul Kyzivat=92s SDP directorate = review comments by clarifying that the =93a=3Drtcp-rgrp:=94 attribute = takes no value. Colin On 25 Aug 2014, at 16:39, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >=20 > Title : Sending Multiple Media Streams in a Single = RTP Session: Grouping RTCP Reception Statistics and Other Feedback > Authors : Jonathan Lennox > Magnus Westerlund > Qin Wu > Colin Perkins > Filename : = draft-ietf-avtcore-rtp-multi-stream-optimisation-04.txt > Pages : 17 > Date : 2014-08-25 >=20 > Abstract: > RTP allows multiple media streams to be sent in a single session, = but > requires each Synchronisation Source (SSRC) to send RTCP reception > quality reports for every other SSRC visible in the session. This > causes the number of RTCP reception reports to grow with the number > of SSRCs, rather than the number of endpoints. In many cases most = of > these RTCP reception reports are unnecessary, since all SSRCs of an > endpoint are co-located and see the same reception quality. This > memo defines a Reporting Group extension to RTCP to reduce the > reporting overhead in such scenarios. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream-optim= isation/ >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-avtcore-rtp-multi-stream-optimisatio= n-04 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-multi-stream-opt= imisation-04 >=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 > _______________________________________________ > 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 25 11:12:16 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/G3vr53s9SZgsZj0q9FNOko5tS0o Cc: "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [AVTCORE] [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:01 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/kfz6yay1RQpcITsx8HqsKbrZ6bI Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Audio/Video Transport Core Maintenance 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:23 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/Wvgf9xL6grfUhZ1aZqPzD_eehAI Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , Colin Perkins , "avt@ietf.org WG" Subject: Re: [AVTCORE] [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:14 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/r5jGvq8tW3baQ6QdH6EfHc6IQ14 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , Colin Perkins , "avt@ietf.org WG" Subject: Re: [AVTCORE] [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Audio/Video Transport Core Maintenance 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 Tue Aug 26 03:17:24 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/Qs3x32NqiKYNzEsjUz1xeI9glSU Cc: "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [AVTCORE] [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:01 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/2arYBTHonCOPcnSofWSwCwMHlyA Cc: "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [AVTCORE] [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:34 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/1g7AYwj7TvINemKft2fT0JAKywE Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: [AVTCORE] Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 08:52:44 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/VT0MxGfcsjns1Yi0Ab9NA9-2xoI Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Audio/Video Transport Core Maintenance 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:57 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/VbQ3zxUu-w7ARMg0HJhviqI-niM Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:20 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/MWmYImda1XOFQ1XRJSdrsHjHJFI Cc: "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [AVTCORE] Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 22:17:25 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/LMVEHcZCyv2O-SQsr80Beso9MqA Cc: "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [AVTCORE] Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Audio/Video Transport Core Maintenance 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:55 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/yfMUIe_hwY65nD-_Fe7sf000iPo Cc: "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [AVTCORE] Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 08:38:50 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/s5orVUe_19-uj_owNpr30ggbw5M X-Mailman-Approved-At: Wed, 27 Aug 2014 08:38:46 -0700 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 Wed Aug 27 08:38:56 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/QJW3WheNOO4gZto3ftdKbAP2lWI X-Mailman-Approved-At: Wed, 27 Aug 2014 08:38:46 -0700 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] [Dart] draft-ietf-dart-dscp-rtp-02 - Section 5.3 RTCP multi-stream optimization text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 Wed Aug 27 08:38:57 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/iglCahszbFP9NaFCpULqNtHPK6o X-Mailman-Approved-At: Wed, 27 Aug 2014 08:38:46 -0700 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 Wed Aug 27 09:01:19 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/WCRloeKFHFYHZfdwi35IRCZSnN8 Cc: "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [AVTCORE] Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:42:50 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/LoPuhpkL2t_TRQ0jK6oWW0beNSM Cc: "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [AVTCORE] [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:50:36 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/9WU-wsfO0PqEBUHk_67dr5eAhd4 Cc: "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [AVTCORE] [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:30 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572D71A0158 for ; Wed, 27 Aug 2014 12:46: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 cQtwSBI_XhuK for ; Wed, 27 Aug 2014 12:46:27 -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 D9D1B1A0107 for ; Wed, 27 Aug 2014 12:46: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 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/avt/O0O5vBaN72T5qxSKnkt6FYDzZ4Q Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , "avt@ietf.org WG" , Michael Welzl Subject: Re: [AVTCORE] [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 19:46:29 -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:48:47 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37C91A0180 for ; Wed, 27 Aug 2014 13:48:44 -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 ysoSi9T9EVnK for ; Wed, 27 Aug 2014 13:48: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 1509D1A026A for ; Wed, 27 Aug 2014 13:48: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 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/avt/XW8e6klG3Hn1pyYPeoHSlKi2w2w Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 20:48:45 -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:42 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/ZhZWtVRb9T27l5TI4pX8ac9KrrY Cc: "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [AVTCORE] Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Audio/Video Transport Core Maintenance 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:35 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/SfHkXRIIjRPvV9c0xer5H55mEGY Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Audio/Video Transport Core Maintenance 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:15 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/EkAmotk3LR7x0gEt7Kq0nHcuKDI Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: [AVTCORE] Treatment of RTCP - proposed text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:13 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FE71A0201 for ; Wed, 27 Aug 2014 19:28: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 iU854-uygY2s for ; Wed, 27 Aug 2014 19:28:10 -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 818C71A015F for ; Wed, 27 Aug 2014 19:28:10 -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/avt/1GctaUiKai2ESrqCHZvuEyWc16o Cc: Michael Welzl , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , "avt@ietf.org WG" , Colin Perkins Subject: Re: [AVTCORE] Treatment of RTCP - proposed text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 02:28:12 -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:42 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/5dEeU3zIWiL0-fDj3Br49D6PdOc Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] Treatment of RTCP - proposed text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Audio/Video Transport Core Maintenance 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:54 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/PI9r2Iu7Gi2g2E4ei_SVFbw1kjE Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , Colin Perkins , Michael Welzl , "avt@ietf.org WG" Subject: Re: [AVTCORE] Treatment of RTCP - proposed text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Audio/Video Transport Core Maintenance 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:16 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458CE1A034A; Wed, 27 Aug 2014 21:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHlYO_wFdWYA; Wed, 27 Aug 2014 21:48:07 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3751A0349; Wed, 27 Aug 2014 21:48:06 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7S4lxLR017660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2014 00:47:59 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s7S4lxLR017660 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1409201280; bh=9DxnFtbxcIa8wJFe5GPj6gmXfww=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=p8uzUj8SBvVRJAk0O2USKpXyUnHv6ku9MyGPr0UEBMEGN90QRZ6rmvaYtZJc7R+45 IvxsQKjobbFtMdLZ0qNI0Hz8ScjPz7C5f5vCdvTIOMbuLGUpnasRMneNMaBonRDvOX WIrOWZMt7Lndd2K86C5bUhq1aMLKAQsFkK3a/kPI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s7S4lxLR017660 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd06.lss.emc.com (RSA Interceptor); Thu, 28 Aug 2014 00:47:30 -0400 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7S4lfLM028512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 00:47:41 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Thu, 28 Aug 2014 00:47:41 -0400 From: "Black, David" 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/avt/tljgMCE-AVs3IXuT9jUo7vP_dsc Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] Treatment of RTCP - proposed text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:34 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/goI0V7xyjAxeJ842ah6NDXuWpWQ Cc: Michael Welzl , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] Treatment of RTCP - proposed text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:27 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/RbQml8CC3nN2nz2MYIfQhdzuhNA Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] [Dart] draft-ietf-dart-dscp-rtp-02 - Section 5.3 RTCP multi-stream optimization text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:58 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/3Pfpbk7KUvLSIunLL2Xv2xTGC04 Cc: "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [AVTCORE] Treatment of RTCP (was Re: [Dart] Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 09:48:36 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/HVfAPzoPciaccfJjeB0Ff1CTslQ X-Mailman-Approved-At: Thu, 28 Aug 2014 09:48:13 -0700 Cc: "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [AVTCORE] [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 18:39:36 -0000 X-List-Received-Date: Wed, 27 Aug 2014 18:39:36 -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 Thu Aug 28 09:48:42 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/sdhKi6wD6yY6sqlMUr_ORcFZt34 X-Mailman-Approved-At: Thu, 28 Aug 2014 09:48:17 -0700 Cc: "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" Subject: Re: [AVTCORE] [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 Thu Aug 28 09:48:44 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/WecVyIhSOuYI_Ih2mhDb_Yws2_c X-Mailman-Approved-At: Thu, 28 Aug 2014 09:48:19 -0700 Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" , Colin Perkins Subject: Re: [AVTCORE] [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 Thu Aug 28 10:31:16 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/Z2DSQJ-4og-tQsSHBJu9667m3sA Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:22 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/mCROXSaNDB8NopgmbH788NUN6Mg Cc: "draft-ietf-dart-dscp-rtp.all@tools.ietf.org" , "Black, David" , "dart@ietf.org" , "avt@ietf.org WG" Subject: Re: [AVTCORE] [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 12:31:10 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AC21A8992 for ; Thu, 28 Aug 2014 12:31:07 -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 sHoWrNBvr4xD for ; Thu, 28 Aug 2014 12:30:59 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3281A896F for ; Thu, 28 Aug 2014 12:30:53 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id i13so1196151qae.15 for ; Thu, 28 Aug 2014 12:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=swGWuB5+FYKRRtTYzcm3BS0IOLzyAzfNPDmN7KHn01g=; b=CTYRwPz8Sm0iqizdeuYYB1EnI7AYt2oUnE/jM3WXOkBf38JfR+R2PEqCEMqyIxNju/ UqS0IN/bbxKtaV7FfB+exn87CaL4NYtfBaaKlEeAXWc54JTFtwkg6uJwGGC/vm/GLNQT fNODNjrEFd8glu6yYzYqbKOlVGJPC3C1kFE3layNmd/h4A3eX1KkYPmeh2xnd4fCzi2N dDrNJNbVhBkNlrOGMoPkHCF9gL/IIXwR1JktY4jCrlOeLVOBVtDRRRxoo/XqvF+H1P94 RETN11FwA2zh7loyH+/dO+lj8IbpTUw4U6VA9O3SoW70SjAki3tR5LHY0SPZQ+9pV6SX dirw== X-Received: by 10.140.27.173 with SMTP id 42mr9177037qgx.59.1409254253230; Thu, 28 Aug 2014 12:30:53 -0700 (PDT) Received: from [192.168.97.130] ([67.210.160.130]) by mx.google.com with ESMTPSA id d62sm6918051qga.38.2014.08.28.12.30.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 12:30:52 -0700 (PDT) Message-ID: <53FF836E.7080800@gmail.com> Date: Thu, 28 Aug 2014 15:30:54 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: avt@ietf.org, Colin Perkins , Michael Welzl References: <704DAEE2-C26F-48C8-8C75-548FE115B91F@csperkins.org> <8D3D17ACE214DC429325B2B98F3AE712077BB42E1F@MX15A.corp.emc.com> <22E25F9C-E9B1-4C3C-989E-570BAAF58018@csperkins.org> <9E8BAB84-3666-4692-8CF1-8FFE285DDF1B@csperkins.org> In-Reply-To: <9E8BAB84-3666-4692-8CF1-8FFE285DDF1B@csperkins.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/avt/8SgR41Ii1m4GGZKuEaEG2GPL0yw Subject: Re: [AVTCORE] [Dart] Treatment of RTCP (was Re: Colin Perkins comments - WGLC: draft-ietf-dart-dscp-rtp-02) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 19:31:07 -0000 On 28/08/2014 2:02 PM, Colin Perkins wrote: ... > >>> 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. > > Wait, sorry, that was the email I replied to a couple of days ago reappearing… RTT probing, I guess :-) > Sorry, the new messages were released from non-member intercept a bit late. I can add Michael to the "always accept" list if he is likely to send a few more messages. Tom Taylor From nobody Thu Aug 28 12:45:36 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/fGc8m39iSOpd2RargdKth859hhY Cc: "Black, David" , "Colin Perkins \(csp@csperkins.org\)" Subject: [AVTCORE] DART dscp-rtp draft: Proposed RTCP text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 19:45:27 -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 13:36:57 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/CQPkaR-xmQKtVeUyQ8eJv0isxJ0 Cc: "Colin Perkins \(csp@csperkins.org\)" Subject: Re: [AVTCORE] DART dscp-rtp draft: Proposed RTCP text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:04 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/t1Y91VxEl5-QLr_ahOmlB5tm59A Cc: "dart@ietf.org" , "avt@ietf.org WG \(avt@ietf.org\)" , "Colin Perkins \(csp@csperkins.org\)" Subject: Re: [AVTCORE] DART dscp-rtp draft: Proposed RTCP text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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:37 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/Qx23TIG2VCa6bLnGXY5-dtXRRTA Cc: "dart@ietf.org" , "avt@ietf.org WG \(avt@ietf.org\)" Subject: Re: [AVTCORE] DART dscp-rtp draft: Proposed RTCP text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 Thu Aug 28 14:01:56 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777D41A01E1; Thu, 28 Aug 2014 14:01:42 -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 9jGKN6d2pOhu; Thu, 28 Aug 2014 14:01:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D39601A0099; Thu, 28 Aug 2014 14:01:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140828210140.6779.75713.idtracker@ietfa.amsl.com> Date: Thu, 28 Aug 2014 14:01:40 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/tT14KmmdZ7O4lHK4hKmpipfIGy0 Cc: avt@ietf.org Subject: [AVTCORE] Last Call: (The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 21:01:42 -0000 The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-09-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the RTP Control Protocol (RTCP). It details three modes of operation (CTR, CCM, GCM) and a SRTP Key Derivation Function for ARIA. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Aug 28 14:04:38 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE95E1A01EE; Thu, 28 Aug 2014 14:04:27 -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 40nwDBMVUm4x; Thu, 28 Aug 2014 14:04:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1181A0154; Thu, 28 Aug 2014 14:04:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140828210425.6779.57711.idtracker@ietfa.amsl.com> Date: Thu, 28 Aug 2014 14:04:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/V04azoddmOV2a5ZlXZBnctnUle8 Cc: avt@ietf.org Subject: [AVTCORE] Last Call: (AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 21:04:28 -0000 The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-09-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines how AES-GCM and AES-CCM Authenticated Encryption with Associated Data algorithms can be used to provide confidentiality and data authentication in the SRTP protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Aug 29 08:17:55 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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/avt/H8ROMhJCCb02VKJb9qANhkHY68s Cc: "dart@ietf.org" , "avt@ietf.org WG \(avt@ietf.org\)" Subject: Re: [AVTCORE] [Dart] DART dscp-rtp draft: Proposed RTCP text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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