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

From: [email-masked]
Date: Fri, 08 Sep 2006 10:50: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 Profile for TCP Friendly Rate Control
	Author(s)	: L. Gharai
	Filename	: draft-ietf-avt-tfrc-profile-06.txt
	Pages		: 13
	Date		: 2006-9-8
	
This memo specifies a profile called "RTP/AVPFCC" for the use of the
real-time transport protocol (RTP) and its associated control
protocol, RTCP, with TCP Friendly Rate Control (TFRC).  This profile
extends the RTP/AVPF profile with RTP data header additions and new
AVPF feedback packets, in order to support TFRCs integration with
RTP.  TFRC is an equation based congestion control scheme for unicast
flows operating in a best effort Internet environment.  This profile
provides RTP flows with the mechanism to use congestion control in
best effort IP networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-tfrc-profile-06.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-06.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-06.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: Ladan Gharai <[email-masked]>
Date: Fri, 8 Sep 2006 17:13:37 -0400

Dear AVT'ers:

A new revision of the "RTP Profile for TCP Friendly Rate Control" is  
now available.

There are a number of changes since the previous version of the  
draft. Most notably that the profile is now an extension of the AVPF  
profile and defines a new AVPF feedback packet for the TFRC algorithm.

An alternative approach to defining a new profile is to use header  
extensions per draft-ietf-avt-rtp-hdrext-04.  There was a general  
extensive discussion of the merit of each approach (new profile  vs.  
use of header extensions) at the last IETF. However, I am not sure if  
a conclusion was gained?

The draft also discusses the issues of RTCP bandwidth for AVPFCC  
flows with relatively small (say less than 20 ms) round trip times.  
The draft recommands abiding by the AVP 5% constraint, however this  
can preclude certain flows with small RTTs.

Please send comments to the list.

thank you,
Ladan

On Sep 8, 2006, at 10:50 AM, [email-masked] wrote:

> Content-Type: text/plain
> Content-ID: <[email-masked]>
>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 15 Sep 2006 13:18:31 +0100

Ladan,

On 8 Sep 2006, at 22:13, Ladan Gharai wrote:
> Dear AVT'ers:
>
> A new revision of the "RTP Profile for TCP Friendly Rate Control"  
> is now available.
>
> draft. Most notably that the profile is now an extension of the  
> AVPF profile and defines a new AVPF feedback packet for the TFRC  
> algorithm.
>
> extensive discussion of the merit of each approach (new profile   
> vs. use of header extensions) at the last IETF. However, I am not  
> sure if a conclusion was gained?

Defining a new profile, with extensions to the fixed RTP header, is  
somewhat more bandwidth efficient than using the mechanisms in rtp- 
hdrext, but is not backwards compatible (and hence there might be  
deployment challenges). Which is best is a design trade-off, with no  
single correct answer, although my personal opinion is that backwards  
compatibility and deployability are more important than saving a few  
octets per packet.

> can preclude certain flows with small RTTs.

We have mechanisms for signalling a different RTCP bandwidth fraction  
[RFC 3566]. I'm curious why they're not used, rather than precluding  
certain flows from using congestion control?

Colin

---

From: Randell Jesup <[email-masked]>
Date: Fri, 15 Sep 2006 11:41:35 -0400

Colin Perkins <[email-masked]> writes:
>> The draft also discusses the issues of RTCP bandwidth for AVPFCC  flows
>> with relatively small (say less than 20 ms) round trip times.  The draft
>> recommands abiding by the AVP 5% constraint, however this  can preclude
>> certain flows with small RTTs.
>
>We have mechanisms for signalling a different RTCP bandwidth fraction  [RFC
>3566]. I'm curious why they're not used, rather than precluding  certain
>flows from using congestion control?

I can't say, but one guess (alluded to in a different context in the last
day) is that RTCP is not ... small.  When being used for this type of
realtime feedback, as opposed to the original usage (primarily reporting),
it rapidly starts eating up a disproportionate percentage of your
bandwidth.  It seems odd to me to spend 10 or 15% (or more! I think it can
end up going over 50%) of my bandwidth just for congestion control (and in
the process making congestion worse...).

Just a guess.

As an aside: I wouldn't be shocked (Hadriel?) if some existing B2BUAs and
SBCs (and QoS setups on cable CMTSes) limit RTCP to 5% regardless of
signalling... :-( That's not a reason to avoid trying, though.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]

---

From: Ladan Gharai <[email-masked]>
Date: Fri, 15 Sep 2006 12:54:06 -0400

> Ladan,

    Hi Colin:

    thank you for the feedback

    please see my comments inline

    Ladan

> deployment challenges). Which is best is a design trade-off, with  
> no single correct answer, although my personal opinion is that  
> backwards compatibility and deployability are more important than  
> saving a few octets per packet.

     the other point that came up at the last AVT session was that  
using defining a profile is more inline with RTP  design principles

     but, as you point out, it essentially boils down to tradeoffs  
and I would be interested in hearing from other AVTers and RTP users  
on their thoughts on the tradeoff - and which design, profile vs.  
extensions, they would be more likely to use/implement
>> flows with relatively small (say less than 20 ms) round trip  
>> times. The draft recommands abiding by the AVP 5% constraint,  
>> however this can preclude certain flows with small RTTs.
>>
>
> We have mechanisms for signalling a different RTCP bandwidth  
> fraction [RFC 3566]. I'm curious why they're not used, rather than  
> precluding certain flows from using congestion control?

     my text was badly worded

     we can certainly use mechanisms that signal using a higher RTCP  
bandwidth on feedback

     but what is the breaking point for too much feedback? 5% 10%  
15% ... 50%?

     for TFRC at small RTTs with RTCP packets things can get out of  
hand quickly

     while this is more a TFRC mechanism issue (does anyone know how  
dccp addresses this?) I do believe that the AVPFCC profile should  
provide some guidelines

---

From: Ladan Gharai <[email-masked]>
Date: Fri, 15 Sep 2006 13:07:02 -0400

On Sep 15, 2006, at 11:41 AM, Randell Jesup wrote:

>>> flows
>> fraction  [RFC

     right - the issue at hand is how much feedback is too much  
feedback? especially as the feedback path is not congestion control

    for the AVPFCC profile, the problem arises at small RTTS (under  
20ms - which really is not that small) and the need for feedback at  
least once every RTT, so as you point out, you can get into  
situations where the feedback bandwidth is 50% of the actual data flow!

   while RTCP packets are not small, modifying them to be smaller,  
would not really solve the problem for the AVPFCC profile and would  
just push it to down to lower RTTs

   the real question (which is out of the scope for the draft) here  
is do rate based congestion control schemes really, really need  
feedback once per RTT (at small RTTs) in order to be fair to other  
flows and react to congestion in a timely manner

---

From: Colin Perkins <[email-masked]>
Date: Mon, 18 Sep 2006 10:33:34 +0100

>> On 8 Sep 2006, at 22:13, Ladan Gharai wrote:
...
>     we can certainly use mechanisms that signal using a higher RTCP  

Okay - the draft could do with a reference to RFC 3566.

>     but what is the breaking point for too much feedback? 5% 10%  

What would be the size of the feedback flow if using TCP or DCCP?  
Being not worse than those transports would be a good start.

Cheers,
Colin

---

From: Ladan Gharai <[email-masked]>
Date: Mon, 18 Sep 2006 18:59:26 -0400

On Sep 18, 2006, at 5:33 AM, Colin Perkins wrote:

>>> fraction [RFC 3566]. I'm curious why they're not used, rather  
>>> than precluding certain flows from using congestion control?
>>>
>>
>>     my text was badly worded
>>
>>     we can certainly use mechanisms that signal using a higher  
>> RTCP bandwidth on feedback
>>
>

    Certainly. I will add a reference (and discussion) to 3566 in the  
next revision of the draft.
>>     while this is more a TFRC mechanism issue (does anyone know  
>> how dccp addresses this?) I do believe that the AVPFCC profile  
>> should provide some guidelines
>>
>

     I dont believe there is a problem for TCP,  since it is ack  
based. In TCP feedback is indirectly congestion controlled too, as  
halving the send rate will result in less feedback (ack) packets as  
well.

    Not sure what dccp does for CCID3 and 4?

---

From: Randell Jesup <[email-masked]>
Date: Mon, 18 Sep 2006 21:46:30 -0400

Ladan Gharai <[email-masked]> writes:
>>>     but what is the breaking point for too much feedback? 5% 10%  15%
>>> ... 50%?
>>>
>>>     for TFRC at small RTTs with RTCP packets things can get out of  hand
>>> quickly

>> What would be the size of the feedback flow if using TCP or DCCP?  Being
>> not worse than those transports would be a good start.
>
>     I dont believe there is a problem for TCP,  since it is ack  based. In
>TCP feedback is indirectly congestion controlled too, as  halving the send
>rate will result in less feedback (ack) packets as  well.

I think Colin was asking how high the % used for feedback in TCP is for
roughly equivalent flow scenarios (RTT, size, etc).  I suspect it's (much)
lower, especially for short RTTs (less than say 2 or 3x the packet send
rate, and especially when RTT approaches or is less than the packet rate).

I'm assuming discrete frames of data stuffed into a TCP pipe every N
milliseconds, with no significant accumulation before sending a packet.
For example, G.729 @ 32 bytes + TCP every 20ms; PCMU @ circa 172 bytes +
TCP overhead every 20ms; or say a 1400 byte video codec packet every 33ms.

---

From: Ladan Gharai <[email-masked]>
Date: Thu, 21 Sep 2006 15:49:14 -0400

On Sep 18, 2006, at 9:46 PM, Randell Jesup wrote:

>> based. In

     Right - it is a useful baseline, however it is independent of  
the RTT.

     A TCP ack packet is  at least 40 bytes (20 IP header + 20 TCP  
header), and at most 100 bytes (+ 60 bytes of TCP options).

    So, in the instance where TCP is sending 1500 byte segments, and  
1 ack-per-packet (that is no delayed acks are used) the feedback  
traffic would be 2.6% (no options) to 6.6% (with options) of the data  
traffic.

> TCP overhead every 20ms; or say a 1400 byte video codec packet  

    I'm not sure how prevalent it is for TCP to not accumulate? In  
such a case, assuming 1 TCP packet per audio frame, the feedback  
percentages would be higher:

    G.729: 40+32 bytes data packet to 40 byte feedback packet: 55%
    PCMU: 40+172 bytes data packet to 40 byte feedback packet:  18%

In all of these numbers, I am assuming that an ack is sent per  
packet, and not every other packet.  TCP does have mechanisms for  
sending delayed acks, or send acks per every other data packet.

---

From: Randell Jesup <[email-masked]>
Date: Thu, 21 Sep 2006 18:00:32 -0400

Ladan Gharai <[email-masked]> writes:
>    I'm not sure how prevalent it is for TCP to not accumulate? In  such a
>case, assuming 1 TCP packet per audio frame, the feedback  percentages
>would be higher:

Using TCP_NODELAY on TCP should generate one packet/frame - and you
probably want TCP_NODELAY for audio/video/rtp data... :-)

>In all of these numbers, I am assuming that an ack is sent per  packet, and
>not every other packet.  TCP does have mechanisms for  sending delayed
>acks, or send acks per every other data packet.

Thanks; I think that gives us some upper bounds.