Subject: [AVT] Comments on draft-gharai-avt-tfrc-profile-00.txt

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Feb 2004 16:23:54 +0100

Hi,

This draft is a very interesting piece of work. It contains a number of 
interesting issues. Of which the first one is:

Should we do this work in AVT? My personal opinion is that doing this is 
probably a good thing. I am not especially optimistic about a quick 
deployment of DCCP thus making it possible to use TFRC that way.

I think that AVT is the right group for doing the profile as we know RTP 
and RTCP best. However we will need TFRC expertise to join AVT so that 
we don't miss some important limitation and ensure that TFRC will work 
well.

This is all something that will need discussion with our AD. Before we 
can do this work we will need a recharter.

Further issues that will need to be discussed is:

- I think that using a profile for this is probably the right way. Not 
for the reason of the header changes which would make it required, 
rather for the signalling that both end points needs to support the 
feedback gathering and reporting correctly. This will clearly increase 
the number of profiles with 2-4 new profiles. The reason is that the old 
or on the way profiles needs to be expressed combined with congestion 
control. I would think that combinations with SRTP and AVPF is probably 
needed.

- I think the header extensions proposed should be reconsidered. Adding 
extra overhead if not really needed is not a good thing. As also 
expressed in the draft there seems to be alternatives to the two fields.

Transmission timestamp. First it is possible to use sender side 
measurements to perform the RTT measurements. Secondly the field does 
not need to be 32 bits. I think somewhere around 24-16 bits is 
sufficient. The only reason to add this field in my view seems to be the 
extended feedback it could provide. We could for example fix the jitter 
calculations by basing them on this field, instead of the display 
timestamp.

The RTT field. To this field there are multiple alternatives. First, run 
RTCP XR RTT measurements in each RTCP packet from the receiver. Thus 
enabling the client to measure the RTT by itself. This would also be 
consistent if a receiver is a sender also. Second alternative would be 
to let the sender report the RTT to the receiver in each RTCP packet 
from the sender.

- I think extending the receiver report is a bad choice. I think putting 
this extended report in another RTCP packet type is a better choice. One 
alternative to a new RTCP packet type would be to use XR, where there is 
a lot of extra code points.

The reason I see for not changing the RTP or RTCP RR packets is that 
this will require more implementation change than using the other 
possibilities. This might not be an issues for the end-points as they 
will anyway need to add extensions to their implementations. However to 
destroy for 3rd party monitors seems to be a bad idea. Also the RTP 
header is already rather big, we should avoid making it bigger.

- Further the changes in the timing rules will need to be more closely 
considered. The profile will basically require that one send at least 
one RTCP packet per RTT. Thus the normal RTCP bandwidth assignment rules 
goes mostly out of the window. Would also needs to consider how one can 
use bandwidth limits or something other to determine how often RTCP 
packets with more data can be sent. If one needs to send on RTCP every 
RTT the RTCP bandwidth becomes dependent on the RTCP packet size and the 
RTT only. Should some type of feedback path congestion control be 
included in this? Is it time to start sequence number the RTCP packets 
to determine the loss rate in the RTCP channel?

- The proposal needs signalling for a number of attributes. This would 
also need to be worked out when we know what needs signalling.

Based on this, I would say that this is a significant amount of work for 
the WG to undertake. Thus I would like to hear the opinion of the 
participants in the WG about it.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Ladan Gharai <[email-masked]>
Date: Tue, 24 Feb 2004 18:44:42 -0500

Magnus:

Thank you for your input. Please see comments inline.

On Feb 20, 2004, at 10:23 AM, Magnus Westerlund wrote:

> Hi,
>
> This draft is a very interesting piece of work. It contains a number 
> of interesting issues. Of which the first one is:
>
> Should we do this work in AVT? My personal opinion is that doing this 
> is probably a good thing. I am not especially optimistic about a quick 
> I think that AVT is the right group for doing the profile as we know 
> RTP and RTCP best. However we will need TFRC expertise to join AVT so 
> that we don't miss some important limitation and ensure that TFRC will 
> work well.
>
> the number of profiles with 2-4 new profiles. The reason is that the 
> old or on the way profiles needs to be expressed combined with 
> congestion control. I would think that combinations with SRTP and AVPF 
> is probably needed.
>
> - I think the header extensions proposed should be reconsidered. 
> Adding extra overhead if not really needed is not a good thing. As 
> also expressed in the draft there seems to be alternatives to the two 
> fields.

    I agree in the general principle of not adding overhead to the RTP 
header - but it should not be avoided at the cost of increasing 
bandwidth  on the reverse path.
> sufficient. The only reason to add this field in my view seems to be 
> the extended feedback it could provide. We could for example fix the 
> jitter calculations by basing them on this field, instead of the 
> display timestamp.

    The main purpose of the transmission timestamp is  to facilitate  
computation of  the loss event rate at the receiver. Clearly,  it can 
also be used for RTT, jitter and other calculations.

    As to the size of the field (if I have done the math correctly) at 
90kHhz  a 16bit timestamp would wrap around in less than a second,  not 
sufficient.  A  24bit field would wrap around in 186sec, which should 
be sufficient, as the loss event calculations are typically done over 8 
to 16 TFRC loss intervals.

>
> The RTT field. To this field there are multiple alternatives. First, 
> run RTCP XR RTT measurements in each RTCP packet from the receiver. 
> Thus enabling the client to measure the RTT by itself. This would also 
> be consistent if a receiver is a sender also. Second alternative would 
> be to let the sender report the RTT to the receiver in each RTCP 
> packet from the sender.

Two factors influence the approach taken for RTT measurement: 1)  how 
often does the RTT need to be updated? and 2) how much extra bandwidth 
is being incurred on the reverse (or forward) path?
     While the current approach of adding 32bits to the RTP payload is 
undesirable due to overhead (perhaps we can allocate 22 to the 
transmission timestamp and 10 to the RTT?) it has the added simplicity 
of continuously  updating the receiver and not requiring running RTCP 
XR RTT measurements or having the sender also generate a RTCP packets 
every RTT.

> - I think extending the receiver report is a bad choice. I think 
> putting this extended report in another RTCP packet type is a better 
> choice. One alternative to a new RTCP packet type would be to use XR, 
> where there is a lot of extra code points.

   Both defining a new packet type and extending the receiver reports 
are good options. My choice of receiver reports was influenced by 
RFC3550's  recommendation of extensions over new packet types (section 
6.4.3)

> one RTCP packet per RTT. Thus the normal RTCP bandwidth assignment 
> rules goes mostly out of the window. Would also needs to consider how 
> one can use bandwidth limits or something other to determine how often 
> RTCP packets with more data can be sent. If one needs to send on RTCP 
> every RTT the RTCP bandwidth becomes dependent on the RTCP packet size 
> and the RTT only. Should some type of feedback path congestion control 
> be included in this? Is it time to start sequence number the RTCP 
> packets to determine the loss rate in the RTCP channel?
>
> Based on this, I would say that this is a significant amount of work 
> for the WG to undertake. Thus I would like to hear the opinion of the 
> This communication is confidential and intended solely for the 
> addressee(s). Any unauthorized review, use, disclosure or distribution 
> is prohibited. If you believe this message has been sent to you in 
> error, please notify the sender by replying to this transmission and 
> delete the message without disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data corruption, 
> interruption, unauthorized amendment, tampering and viruses, and we 
> only send and receive e-mails on the basis that we are not liable for 
> any such corruption, interception, amendment, tampering or viruses or 
> any consequences thereof.
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Feb 2004 13:10:17 +0100

Hi Ladan,

comments inline.

> bandwidth  on the reverse path.

I think the trade off would need analyses. For the first would using 
RTCP with extensions be sufficient for TFRC's need? Secondly how big 
overhead would really be introduced in either solution. Third some of 
the RTCP overhead would be in both directions. The reason I consider the 
trade-off is the RTP to RTCP rates. Without TFRC there will normally be 
rather many RTP packets for every RTCP packet. With one RTCP per RTT 
this will no longer be general true, risk of low RTT transport plus few 
RTP packets could at worst case be less than one RTP packet per RTCP 
packet. RTT 10 ms means that one must send 100 RTP packets per second to 
have one RTP packet per RTCP packet. Thus the overhead trade off is a 
bit harder. However at the same time you will need to send one receiver 
to sender feedback message every RTT anyway.

> also be used for RTT, jitter and other calculations.

Having looked at RFC 3448 I see that a transmission timestamp seems to 
be needed for determining what loss event each loss should belong to. 
However the resolution necessary for this purpose seems to be four 
increments per interval. Thus a 32-bit timestamp seems unnecessary 
large, more about this below.

> sufficient.  A  24bit field would wrap around in 186sec, which should be 
> sufficient, as the loss event calculations are typically done over 8 to 
> 16 TFRC loss intervals.

But you used a 90 kHz clock. My idea for this field would be to use a 
fixed clock rate, not connect it to the media clock rate at all. Thus 
one can ensure one has sufficient resolution, while being able to more 
efficiently adapt the size of the field. I think a fixed clock rate of 
somewhere between 1000 and 10000 Hz would be suitable. Input into this 
is certainly a topic of discussion. A quick glance at RFC 3448 seems to 
indicate that this transmission timestamp does not need any huge 
resolution, milliseconds is probably more than sufficient.

As a side note, how does TFRC behaves when the packet transmission rate 
drops below one packet per RTT? I think this case can be rather common 
for local area networks.

> of continuously  updating the receiver and not requiring running RTCP XR 
> RTT measurements or having the sender also generate a RTCP packets every 
> RTT.

I understand the reasoning. But don't you anyway needs to send one RTCP 
packet from receiver to sender every RTT to ensure that the sender gets 
feedback for each RTT interval. Thus if this traffic goes there anyway 
and the overhead in RTP or RTCP is on the same order of magnitude, then 
having the necessary information in RTCP would avoid sending it more 
often than needed.

>   Both defining a new packet type and extending the receiver reports are 
> good options. My choice of receiver reports was influenced by RFC3550's  
> recommendation of extensions over new packet types (section 6.4.3)
> 

In my opinion changing the RR or SR packets creates a higher 
implementation burden thus making the deployment a bit harder. However I 
think this discussion can wait until we know what fields that needs to 
be transported, how often, and how big they are. At that time we will 
have the necessary input into this discussion.

Cheers

Magnus Westerlund