Re: [AVT] I-D ACTION:draft-ietf-avt-tfrc-profile-09.txt

Ladan Gharai <ladan@ISI.EDU> Mon, 23 July 2007 00:46 UTC

Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICm4X-0008H7-NF; Sun, 22 Jul 2007 20:46:49 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICm4V-0008Fm-J6 for avt@ietf.org; Sun, 22 Jul 2007 20:46:47 -0400
Received: from porter.east.isi.edu ([65.114.168.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICm4V-0006Av-0M for avt@ietf.org; Sun, 22 Jul 2007 20:46:47 -0400
Received: from [192.168.1.101] (pool-70-108-44-91.res.east.verizon.net [70.108.44.91]) by porter.east.isi.edu (Postfix) with ESMTP id 51A071CAC; Sun, 22 Jul 2007 20:46:46 -0400 (EDT)
In-Reply-To: <2CD7768D-70A2-4149-9FD4-80096D8BD564@csperkins.org>
References: <E1I8JIk-0006Cs-6P@stiedprstage1.ietf.org> <2CD7768D-70A2-4149-9FD4-80096D8BD564@csperkins.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <BC29FF89-8508-4D9D-876B-2312897C456C@ISI.EDU>
Content-Transfer-Encoding: 7bit
From: Ladan Gharai <ladan@ISI.EDU>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-tfrc-profile-09.txt
Date: Sun, 22 Jul 2007 20:46:41 -0400
To: Colin Perkins <csp@csperkins.org>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Cc: AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org

Colin:

Thank you for your comments. I have just submitted newer version  
incorporating all the comments I have received. Regarding the  
timestamps please see inline:

Ladan

On Jul 21, 2007, at 5:14 AM, Colin Perkins wrote:

> On 10 Jul 2007, at 18:15, 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 Working  
>> Group of the IETF.
>>
>> 	Title		: RTP with TCP Friendly Rate Control
>> 	Author(s)	: L. Gharai
>> 	Filename	: draft-ietf-avt-tfrc-profile-09.txt
>> 	Pages		: 11
>> 	Date		: 2007-7-10
>> 	
>> This memo specifies how the TCP Friendly Rate Control (TFRC) of RTP
>>    flows can be supported using the RTP/AVPF profile and the  
>> general RTP
>>    header extension mechanism.  AVPF feedback packets and RTP header
>>    extensions are defined to support the exchange of control  
>> information
>>    between RTP TFRC senders and receivers. TFRC is an equation-based
>>    congestion control scheme for unicast flows operating in a best
>>    effort Internet environment.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-avt-tfrc- 
>> profile-09.txt
>
> Reading this, I was surprised that timestamps are specified in  
> microseconds, rather than RTP timestamp units. Is there a reason  
> for this choice? Using RTP timestamp units would seem easier, since  
> it requires only a single clock, and would also allow delta-coding  
> of timestamp relative to the timestamp in the RTP header, to reduce  
> packet sizes.

    The reasoning for using  microseconds timestamps is that these  
timestamps are used to measure the RTT time,  determine when a lost  
packet would/should have arrived, etc - essentially, these timestamps  
have really been added for  the "transport domain" rather than the  
"media domain". If the timestamps were is RTP timestamp units, a  
conversion to seconds would be needed before being used in the  
"transport domain", and so the logic is to avoid having to convert  
the timestamp in the main domain for which it will be used.

>
> The IANA considerations section outlines what is needed in general,  
> but needs to be specific about exactly what changes are needed to  
> the registries.

    I have added more specifics here.
>
> The discussion of SDP usage is very limited. I think the draft  
> needs to include an Offer/Answer considerations section, explaining  
> how this is used in both negotiated and declarative modes. Examples  
> of session setup messages using both SIP and (especially) RTSP  
> would be useful.

    I will add text on this in the next revision.
>
> Finally, the idnits tools finds a number of problems, which must be  
> fixed before we can progress this draft:

    done
>
>   Checking nits according to http://www.ietf.org/ietf/1id- 
> guidelines.txt:
>   - No 'Intended status' indicated for this document; assuming  
> Proposed
>     Standard
>
>   Checking references for intended status: Proposed Standard
>   - Unused Reference: 'RFC2434' is defined on line 391, but not  
> referenced
>   - Unused Reference: 'RFC3551' is defined on line 400, but not  
> referenced
>   - Unused Reference: 'RFC4342' is defined on line 423, but not  
> referenced
>   * Obsolete Normative Reference: RFC 2327
>   * Downref: Informational Normative Reference: RFC 4336
>   - No information found for draft-ietf-avt-profile-savpf-xx - is  
> the name
>     correct?
>   - Possible downref: Draft Normative Reference: ref. 'SAVPF'
>   - No information found for draft-phelan-dccp-dtls-xx - is the  
> name correct?
>   - Possible downref: Draft Normative Reference: ref. 'ID.DTLS'
>
>     Summary: 2 errors, 8 warnings
>
> -- 
> Colin Perkins
> http://csperkins.org/
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt