[AVTCORE] WGLC review on draft-ietf-avtcore-multi-media-rtp-session-09

"Asveren, Tolga" <tasveren@sonusnet.com> Sun, 06 September 2015 13:24 UTC

Return-Path: <tasveren@sonusnet.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181D51B574A for <avt@ietfa.amsl.com>; Sun, 6 Sep 2015 06:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 0EML8XoJ_pLp for <avt@ietfa.amsl.com>; Sun, 6 Sep 2015 06:24:15 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0058.outbound.protection.outlook.com [207.46.100.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CA01B5747 for <avt@ietf.org>; Sun, 6 Sep 2015 06:24:15 -0700 (PDT)
Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.262.15; Sun, 6 Sep 2015 13:24:12 +0000
Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0262.011; Sun, 6 Sep 2015 13:24:12 +0000
From: "Asveren, Tolga" <tasveren@sonusnet.com>
To: "avt@ietf.org" <avt@ietf.org>
Thread-Topic: WGLC review on draft-ietf-avtcore-multi-media-rtp-session-09
Thread-Index: AdDopuWwqzJXoS5ySHaPjTeK331l7A==
Date: Sun, 6 Sep 2015 13:24:12 +0000
Message-ID: <SN1PR0301MB1551A9ACE98A1BA9E733CDFAB2550@SN1PR0301MB1551.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com;
x-originating-ip: [50.182.164.80]
x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:vW+F1fdecWxBLxbIGb/2U1nABMoP2bbt3cUdshaVjlTrM0ARoZVputuokiClCDWrwsQUSJ4SDmcwRiCfPSSE8Ne9QA4syfX2cXVu33CZt3rEpFmOkQ3Y8uX2qemJnM6D3dtWG6XEzl6z+L2lsteCug==; 24:t8ZUBpVCMG34bT34oE8zHXt+ls9GEMHWYPQD5ISrRIwF4sGt5n1zNF4DJkoFs+AGDMtF0k9Hz9RYT7rSAZJ+Zcc66m/xVL+xig1JLgkTyOI=; 20:WYG7L+4NC6jdsJ1Q3UOp2YbL7iH1CsyQixVKlw6X3OeYLWWKOw4JrJGgtJ+vO6Ss1eGNPcbLC5GvqeB74SisVA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549;
x-microsoft-antispam-prvs: <SN1PR0301MB154900BA1A96DDCB284FD492B2550@SN1PR0301MB1549.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549;
x-forefront-prvs: 06911FE69E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(377454003)(164054003)(13464003)(189002)(87936001)(450100001)(62966003)(97736004)(77156002)(74316001)(81156007)(33656002)(54356999)(50986999)(4001540100001)(5007970100001)(10400500002)(77096005)(5004730100002)(230783001)(102836002)(68736005)(86362001)(99286002)(76576001)(105586002)(5001860100001)(5001830100001)(64706001)(2351001)(106356001)(92566002)(5003600100002)(122556002)(2900100001)(66066001)(40100003)(229853001)(189998001)(46102003)(2501003)(5002640100001)(19580395003)(5001960100002)(19580405001)(110136002)(107886002)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: sonusnet.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2015 13:24:12.7467 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/cUfXH02Qzc5Oq9lP7ZA0fZzk_nE>
Subject: [AVTCORE] WGLC review on draft-ietf-avtcore-multi-media-rtp-session-09
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Sep 2015 13:24:17 -0000

I did not monitor the progress of this draft over its lifetime, so this is more of an "outsider's review" (which probably is useful in its own right)

i- 2. Terminology
"Media Type:  The general type of media data used by a real-time
      application.  The media type corresponds to the value used in the
      <media> field of an SDP m= line.  The media types defined at the
      time of this writing are "audio", "video", "text", "application",
      and "message"."

- It could be good to provide a reference to the corresponding IANA registry.
- I know it is not very common but still defined/possibly used, is there a specific reason not to include "image" (e.g., image/t38, image/g3fax) in this list?

ii- 3.  Background and Motivation
In general, this section seems trying to do a "hard sell", which IMHO can be softened up a little bit.

- "However, we note that many RTP-using application don't use network
   QoS features, and don't expect or desire any separation in network
   treatment of their media packets, independent of whether they are
   audio, video or text.  When an application has no such desire, it
   doesn't need to provide a transport flow structure that simplifies
   flow based QoS."
This really depends on the environment and deployment model. In addition to that, providing QoS with DiffServ is still possible when multiple types of media are sent in a single RTP session as explained in draft-ietf-dart-dscp-rtp (which is already referenced by this draft)

-  "1.  increased delay to establish a complete session, since each of
       the transport layer flows needs to be negotiated and established;"
At least negotiation part can happen in parallel. And when multiple streams use the same RTP session, isn't there still a need to negotiate different SSRC values, one per stream? A reference to RFC5576 could be useful as well.

iii- 5.3.  Per-SSRC Media Type Restrictions 
This section provides the justification why different SSRC but be used for audio and video streams but not really why a SSRC can't be re-used for streams of different type. It would be good to cover that aspect as well.

iv- 4.  Applicability
"Compatible RTCP Behaviour:  The RTCP timing rules enforce a single
      RTCP reporting interval for all participants in an RTP session.
      Flows with very different media sending rate or RTCP feedback
      requirements cannot be multiplexed together, since this leads to
      either excessive or insufficient RTCP for some flows, depending
      how the RTCP session bandwidth, and hence reporting interval, is
      configured."
This part IMHO requires more justification. Why is it not possible to send RTCP in different rates for different flows? Some RTCP packets could have reports pertaining to a single stream whereas the other ones (when timing for reports for different streams overlaps or is sufficiently close enough) for multiple streams. Aggregate RTCP bandwidth need shouldn't be a constraining factor just because a single transport flow is used AFAICS. If that is not the case, it really could be useful to explain why.

v- 7.  Signalling
"When using SDP signalling, the BUNDLE extension
[I-D.ietf-mmusic-sdp-bundle-negotiation] is used to signal RTP
sessions containing multiple media types."
It could be a good idea to reference relevant sections as the bundle-draft has some irrelevant aspects (arguably which even could be confusing in the context of this specification).

Thanks,
Tolga

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus
> Westerlund
> Sent: Friday, September 04, 2015 3:31 AM
> To: rtcweb@ietf.org
> Subject: [rtcweb] Fwd: [AVTCORE] WGLC on draft-ietf-avtcore-multi-media-
> rtp-session-09
> 
> RTCWEB WG,
> 
> As an author of these documents I want to inform you that there is a
> relevant WG last call that ends in another 6 days.
> 
> RTCWEB is a consumer of this document, please review and send feedback
> to AVTCORE WG.
> 
> Cheers
> 
> Magnus Westerlund