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

"Asveren, Tolga" <tasveren@sonusnet.com> Thu, 10 September 2015 10:27 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 BAD081B63A8 for <avt@ietfa.amsl.com>; Thu, 10 Sep 2015 03:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UNlgNL0j7YVG for <avt@ietfa.amsl.com>; Thu, 10 Sep 2015 03:27:15 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0636.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:636]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD571B327E for <avt@ietf.org>; Thu, 10 Sep 2015 03:27:14 -0700 (PDT)
Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1550.namprd03.prod.outlook.com (10.162.129.156) with Microsoft SMTP Server (TLS) id 15.1.262.15; Thu, 10 Sep 2015 10:27:11 +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; Thu, 10 Sep 2015 10:27:11 +0000
From: "Asveren, Tolga" <tasveren@sonusnet.com>
To: Colin Perkins <csp@csperkins.org>
Thread-Topic: [AVTCORE] WGLC review on draft-ietf-avtcore-multi-media-rtp-session-09
Thread-Index: AdDopuWwqzJXoS5ySHaPjTeK331l7AAulY4AAJNJtnA=
Date: Thu, 10 Sep 2015 10:27:10 +0000
Message-ID: <SN1PR0301MB1551950D49EF85F18389FBE0B2510@SN1PR0301MB1551.namprd03.prod.outlook.com>
References: <SN1PR0301MB1551A9ACE98A1BA9E733CDFAB2550@SN1PR0301MB1551.namprd03.prod.outlook.com> <0BB62428-98D7-4B48-AF91-1D1CCE33BCF5@csperkins.org>
In-Reply-To: <0BB62428-98D7-4B48-AF91-1D1CCE33BCF5@csperkins.org>
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; SN1PR0301MB1550; 5:a1vlxpEv3af1/oD/RmYmXvkSjnTGCLVOjWNzwUpUzpB64SeDHWiYFI7LilUtOxm07+Q2jFVzUv2UGDrvWMIZNzkG+gZam6Qb9pnYKBfSQ9r/EH53FMf7av7s6EvJQrQT2hRYNmysOkKuNdXH1l/IQQ==; 24:FKWRzoYq+8FJGfF1Tpg10Q3z93Ki60dOpU5maauKmIzkMhIJ7KsQgbKTn0xMZMsAbhgQ3TnEqoRysmtqKE5r6ttzV/dQK3qod/qYNmMlag4=; 20:mx+bRo1qy/1lAPn8yX9+SH5KRPaVB8TS1z3bjNlcJ7bP1BSsWLYSibw/B9DkXSk+l69yTZP5kaeZiYosZs2jmQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1550;
x-microsoft-antispam-prvs: <SN1PR0301MB15500DDD81A7E9069FB84B22B2510@SN1PR0301MB1550.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:SN1PR0301MB1550; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1550;
x-forefront-prvs: 06952FC175
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(51914003)(13464003)(199003)(164054003)(189002)(377454003)(92566002)(122556002)(110136002)(5001960100002)(189998001)(87936001)(5002640100001)(15975445007)(11100500001)(102836002)(77156002)(68736005)(62966003)(64706001)(5007970100001)(86362001)(50986999)(5001860100001)(46102003)(5003600100002)(230783001)(76176999)(105586002)(5001830100001)(10400500002)(54356999)(5004730100002)(19580395003)(77096005)(97736004)(40100003)(33656002)(106356001)(101416001)(4001540100001)(19580405001)(2950100001)(66066001)(76576001)(99286002)(81156007)(74316001)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1550; 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: 10 Sep 2015 10:27:11.0089 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1550
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/1UBWNpBooJrM633IZvJ_pNE87BA>
Cc: Ali Begen <abegen@cisco.com>, "avt@ietf.org" <avt@ietf.org>
Subject: Re: [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: Thu, 10 Sep 2015 10:27:17 -0000

Please see inline for questions/answers/comments.

Thanks,
Tolga

> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Monday, September 07, 2015 7:35 AM
> To: Asveren, Tolga <tasveren@sonusnet.com>
> Cc: avt@ietf.org; Ali Begen <abegen@cisco.com>
> Subject: Re: [AVTCORE] WGLC review on draft-ietf-avtcore-multi-media-rtp-
> session-09
> 
> Hi,
> 
> Thanks for the review; some responses inline.
> 
> On 6 Sep 2015, at 14:24, Asveren, Tolga <tasveren@sonusnet.com> wrote:
> > 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?
> 
> I copied the list from draft-ietf-mmusic-rfc4566bis-15, which doesn't mention
> "image". I agree we should mention it, as should 4566bis. (I've cc'd Ali, for
> comment).
> 
> > 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)
> 
> It's not clear what change you want here. Do you have a suggestion for how
> to update the text?
[TOLGA] Maybe just taking out QoS related part?
> 
> > -  "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.
> 
> Negotiation can only happen in parallel to a certain extent, before the
> amount of STUN traffic causes congestion. The SSRCs also don't necessarily
> have to be negotiated in advance for either model.
[TOLGA] It could be useful to provide more information about how demultiplexing based on SSRC would work when multiple streams are sent in the same RTP session. Isn't there inherently a need to associate a stream with a particular SSRC? How is this done? Just a description of that, maybe in Section 5.2. so that the logic is obvious to people (particularly to first-time readers).
> 
> > 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.
> 
> Sorry, I'm not sure what you're asking here. Can you rephrase?
[TOLGA] Mea culpa, I think 5.3 already explains why the same SSRC can't be re-used for streams of different type:
  "The payload type will inform a receiver which
   media type the SSRC is being used for.  Thus the payload type MUST be
   unique across all of the payload configurations independent of media
   type that is used in the RTP session."
I guess this section provides the justification. Please correct me if I am wrong.
> 
> > 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.
> 
> The RTCP timing rules in RFC 3550 don't support different reporting intervals
> for different SSRCs (other than a sender/receiver split), and doing so runs a
> risk of causing inappropriate RTCP timeouts. We could add a reference to RFC
> 3550 here, if it helps?
[TOLGA] Can't this be changed? On a high level, aren't we talking about two different RTCP streams here? Why should their timing be aligned in any way?
> 
> > 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).
> 
> Can you be specific on how BUNDLE should be referenced?
[TOLGA] Maybe just specifying which sections are relevant and which are not, e.g. "14. RTP/RTCP extensions for identification-tag transport" in draft-ietf-mmusic-sdp-bundle-negotiation-23.txt, is this part relevant to  draft-ietf-avtcore-multi-media-rtp-session-09?
> 
> Cheers,
> Colin
> 
> 
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
>