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

From: [email-masked]
Date: Tue, 10 Jul 2007 13:15:02 -0400

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-avt-tfrc-profile-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-tfrc-profile-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Sat, 21 Jul 2007 10:14:58 +0100

> 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 IANA considerations section outlines what is needed in general,  
but needs to be specific about exactly what changes are needed to the  
registries.

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.

Finally, the idnits tools finds a number of problems, which must be  
fixed before we can progress this draft:

   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/

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 22 Jul 2007 20:47:10 +0200

Colin Perkins skrev:
> timestamp relative to the timestamp in the RTP header, to reduce packet 
> sizes.

Actually I think using this is correct choice. Delta coding put 
restriction on how much difference there can be between the display and 
transport time can be or force a variable field length. having fixed 
length and delta codiding is not robust unless it is 32 bits.

Having one fixed timestamp rate avoids the whole issues with payload 
type switching resulting in clock rate changes. Thus avoiding to create 
additional issue with changing used payload types.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Stephen Casner <[email-masked]>
Date: Sun, 22 Jul 2007 12:09:07 -0700 (PDT)

On Sun, 22 Jul 2007, Magnus Westerlund wrote:

> Colin Perkins skrev:
> > 
> > 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.
> 
> Actually I think using this is correct choice. Delta coding put restriction on
> how much difference there can be between the display and transport time can be
> or force a variable field length. having fixed length and delta codiding is
> not robust unless it is 32 bits.
> 
> Having one fixed timestamp rate avoids the whole issues with payload type
> switching resulting in clock rate changes. Thus avoiding to create additional
> issue with changing used payload types.

On the other hand, having a clock rate unrelated to the media clock
introduces the problem of arithmetic errors.  We had a major debate
about this in the design of RTPv2 after RTPv1.

                                                        -- Steve

---

From: Ladan Gharai <[email-masked]>
Date: Sun, 22 Jul 2007 20:46:41 -0400

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:

> 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.

> 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.
> fixed before we can progress this draft:

    done
>   - No information found for draft-phelan-dccp-dtls-xx - is the  
> name correct?

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Jul 2007 15:44:54 +0200

> about this in the design of RTPv2 after RTPv1.

But, the usage of this clock is not related to the media. It is used to 
determine if you can send a packet or not. So I am wondering if the 
arithmetic error has any real impact.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Mon, 23 Jul 2007 14:47:04 -0500

On 22 Jul 2007, at 19:46, Ladan Gharai wrote:
...
>> 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.
>
> 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.

But the RTT can be derived from RTCP SR packets, and determining when  
a packet should have arrived is a feature of the playout buffer,  
which derives from the RTP timestamp. It seems that using  
microseconds just forces the implementation to use an additional  
clock for little reason (rather than implement all the TFRC timing  
logic using the RTP clock).

-- 
Colin Perkins
http://csperkins.org/

---

From: Ladan Gharai <[email-masked]>
Date: Mon, 23 Jul 2007 15:07:36 -0400

On Jul 23, 2007, at 9:44 AM, Magnus Westerlund wrote:

>>>> microseconds,
>>> restriction on
> But, the usage of this clock is not related to the media. It is  
> used to determine if you can send a packet or not. So I am  
> wondering if the arithmetic error has any real impact.

     Correct. The send timestamp added via  a header extension is  
used to compute the RTT (also in microseconds), the send rate, the  
lost event rate, etc. Expressing the send timestamp in RTP  timestamp  
units will require a conversion to seconds to be done, before the  
timestamp can be used for transport related usage.

---

From: Ladan Gharai <[email-masked]>
Date: Tue, 24 Jul 2007 16:34:40 -0400

On Jul 23, 2007, at 3:47 PM, Colin Perkins wrote:

>> timestamps are used to measure the RTT time,  determine when a  
>> lost packet would/should have arrived, etc - essentially, these  
> But the RTT can be derived from RTCP SR packets, and determining  
> when a packet should have

     Are you saying its OK to have the RTT is seconds/microseconds  
(the RTT calculated using the SR and RR reports is in seconds)

> arrived is a feature of the playout buffer, which derives from the  
> RTP timestamp. It seems that

    right, but TFRC determines the loss intervals by comparing  
arrival times and the RTT - so if the RTT is already in seconds? then  
it be easier to compare the send or arrival time in seconds too

> using microseconds just forces the implementation to use an  
> additional clock for little reason (rather than implement all the  
> TFRC timing logic using the RTP clock).

    But the NTP timestamp used is the SR is wall clock time -  
therefore is the system not already using two clocks?

---

From: Colin Perkins <[email-masked]>
Date: Wed, 25 Jul 2007 11:53:23 -0500

This is why I'm suggesting you use the RTP timestamp rate: it avoids  
all these issues with multiple clocks.

Colin

On 24 Jul 2007, at 15:34, Ladan Gharai wrote:
>>>> 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.
>>>
>>> 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.
>>
> arrival times and the RTT - so if the RTT is already in seconds?  
> then it be easier to compare the send or arrival time in seconds too
>

-- 
Colin Perkins
http://csperkins.org/

---

From: Randell Jesup <[email-masked]>
Date: Thu, 26 Jul 2007 00:26:08 -0400

Colin Perkins <[email-masked]> writes:
>This is why I'm suggesting you use the RTP timestamp rate: it avoids  all
>these issues with multiple clocks.

But can't the RTP timestamp rate change in mid-stream?  (See the
discussions here in the last few months, plus a few other times over the
last few years).  You can't tell exactly when it changed in the face of
packet loss in some situations.  Plus even if you can tell when, it greatly
complicates conversion to real-time deltas if the time crosses a
payload-induced timestamp rate change.

Example:
m=audio 6543 RTP/AVP 99 98 97
a=rtpmap 99 iLBC/8000
a=rtpmap 98 G722/16000
a=rtpmap 97 DVI4_22050 22050

And then the stream switches from payload 99 to 98 to 97 over time (or
even flop/flops back and forth - legal, though incredibly cruel/stupid/silly).

This is a real-world scenario, too - a call may start G722/16000, and
switch to iLBC/8000 if the loss is too high.

(When discussing DTMF/RFC2833/4877 here in the last few months, it was
proposed that to handle DTMF in this situation, excluding the "crosses the
transition" case, just have two payloads defined, one with /8000 and one
with /16000 (or three in the case above).

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)