Re: [AVTCORE] New Packet formats section in Multipath RTP (draft-singh-avtcore-mprtp-01)

varun singh <vsingh.ietf@gmail.com> Fri, 18 March 2011 11:42 UTC

Return-Path: <vsingh.ietf@gmail.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92E33A6800 for <avt@core3.amsl.com>; Fri, 18 Mar 2011 04:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level:
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VNhUfcmx-4R for <avt@core3.amsl.com>; Fri, 18 Mar 2011 04:42:17 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 65A283A6869 for <avt@ietf.org>; Fri, 18 Mar 2011 04:42:17 -0700 (PDT)
Received: by fxm15 with SMTP id 15so3864676fxm.31 for <avt@ietf.org>; Fri, 18 Mar 2011 04:43:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=v5CSKii0uuuUoHbsX028DDrje+MhqY3esAXozvGpQD8=; b=OWf+wAkVrAeNrVxbdmnpcnFOwJraobiwndaEgI/P4wqrhTXdWtETBOvo17a8iGwbyE W/xLj83TPSElZF5krHSPYyX1Ao4fra9pe43Rnw/e7tL6n5ohxTWejTKEDTuqtBWlWyUc cuP5XpxPbKs/M0QCILAd+b09Y8D5ZO1rgxrmo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=UQ83lE5Jk4zE9a6ZlfnQWweBhjZmGMcsC42YSWDb8MeKFTwg5TCgZ5cdUy1Y1M8KJe EzB8DBD09zGG5HOpZml53Qb14NiMpzS0iRu7UprNUIix+QrUz6+rGL8k/QpDNB4osB54 lrK/Oienp/pf0hV4pFjYVfb0ns2w/xk0NEfio=
Received: by 10.223.27.14 with SMTP id g14mr1090321fac.129.1300448626130; Fri, 18 Mar 2011 04:43:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.104.211 with HTTP; Fri, 18 Mar 2011 04:43:26 -0700 (PDT)
In-Reply-To: <005e01cbe3e7$4142abb0$c3c80310$%roni@huawei.com>
References: <AANLkTimiOb29PRXVfDjVp5=Bt2L4hQ_FXychLbCdboaT@mail.gmail.com> <005e01cbe3e7$4142abb0$c3c80310$%roni@huawei.com>
From: varun singh <vsingh.ietf@gmail.com>
Date: Fri, 18 Mar 2011 13:43:26 +0200
Message-ID: <AANLkTimv+_mKb76hJ7wfTQDDXegLBFENwkHcciyZRKsQ@mail.gmail.com>
To: Roni Even <Even.roni@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: avt@ietf.org
Subject: Re: [AVTCORE] New Packet formats section in Multipath RTP (draft-singh-avtcore-mprtp-01)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Mar 2011 11:42:20 -0000

Hi Roni,


On Wed, Mar 16, 2011 at 16:34, Roni Even <Even.roni@huawei.com> wrote:
> Hi,
> I noticed that in the document you talk about RTCP header extension (section
> 8.1, 9.1) yet it looks to me like you define a new RTCP packet type and not

We mean the latter, MPRTP requires new RTCP packet types.

> an extension to RTCP SR or RR. Please clarify and if you define new packets
> it will be better to use one RTCP packet type.

We will make alterations to the packet formats to reduce it to using
one RTCP packet type.
An alternative to a new RTCP packet type would be to define these RTCP
packets as App Packets (PT=204). However, I don't think MPRTP fits the
definition of Application defined packet.


Additionally, I'm also looking for comments on the packet format
defined in 9.3 (if reusing and re-encapsulating other RTCP packet
types) is a good idea or not.




>
> Regards
> Roni Even
>
>> -----Original Message-----
>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
>> varun singh
>> Sent: Monday, March 14, 2011 11:57 PM
>> To: avt@ietf.org
>> Subject: [AVTCORE] New Packet formats section in Multipath RTP (draft-
>> singh-avtcore-mprtp-01)
>>
>> Greetings,
>>
>> We have updated the draft and the latest iteration contains an updated
>> section on Packet Formats (Section 9). In Section 9.3.1, we define a
>> generic mechanism to reuse the session level reports (e.g., SR, RR,
>> XR) for subflow-specific reports. An example non-compound subflow
>> MPRTCP is shown in Figure 12.
>>
>> For exact changes see
>> http://tools.ietf.org/rfcdiff?url2=draft-singh-avtcore-mprtp-01.txt.
>>
>> The draft contains some open issues (and some recommendations) that
>> should be discussed here on the mailing so that we can move ahead and
>> close them.
>>
>> Regards,
>> Varun
>>
>> Begin forwarded message:
>>
>> A new version of I-D, draft-singh-avtcore-mprtp-01.txt has been
>> successfully submitted by Varun Singh and posted to the IETF
>> repository.
>>
>> Filename:      draft-singh-avtcore-mprtp
>> Revision:      01
>> Title:                 Multipath RTP (MPRTP)
>> Creation_date:         2011-03-14
>> WG ID:                 Independent Submission
>> Number_of_pages: 29
>>
>> Abstract:
>> The Real-time Transport Protocol (RTP) is used to deliver real-time
>> content and, along with the RTP Control Protocol (RTCP), forms the
>> control channel between the sender and receiver.  However, RTP and
>> RTCP assume a single delivery path between the sender and receiver
>> and make decisions based on the measured characteristics of this
>> single path.  Increasingly, endpoints are becoming multi-homed, which
>> means that they are connected via multiple Internet paths.  Network
>> utilization can be improved when endpoints use multiple parallel
>> paths for communication.  The resulting increase in reliability and
>> throughput can also enhance the user experience.  This document
>> extends the Real-time Transport Protocol (RTP) so that a single
>> session can take advantage of the availability of multiple paths
>> between two endpoints.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>> Varun Singh
>> http://www.netlab.tkk.fi/~varun
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
>
>