Subject: RE: Re-send: Simple estimate for Nr. of retransmissions (WAS:RE: [AVT] IESG comments on draft-ietf-avr-rtp-retransmission-11.txt - Issue 4: more parameters needed for RTX?)

From: "Jose Rey" <[email-masked]>
Date: Mon, 15 Aug 2005 18:39:21 +0200

Hi Magnus, all,

There has not been more feedback on this, so I guess the estimate is
acceptable (?) Do we need more time for this or shall I submit it to the
IESG already?

I have reviewed the details again and made the assumptions a bit
clearer.  I still have one question to Magnus: you said the
avg_rtcp_size would be around 125 bytes.  Is this based on your
experience? 

The attached text below includes the proposed changes to the draft in
proper format.   

Looking forward to your feedback,

---------------------------------------------
Jose Rey     mailto:[email-masked]
P R D C G - Panasonic R&D Center Germany GmbH
Phone/Fax: +49(0)6103766-134/166
--------------------------------------------- 

---
---
Proposed changes:

Section 6.3 Retransmission requests

OLD:

   ...

   To increase the robustness to the loss of a NACK or of a 
   retransmission packet, a receiver may send a new NACK for the same 
   packet.  This is referred to as multiple retransmissions.  Before 
   sending a new NACK for a missing packet, the receiver should rely 
   on a timer to be reasonably sure that the previous retransmission 
   attempt has failed in order to avoid unnecessary retransmissions. 
    
   NACKs MUST be sent only for the original RTP stream.  Otherwise, 
   if a receiver wanted to perform multiple retransmissions by 
   sending a NACK in the retransmission stream, it would not be able 
   to know the original sequence number and a timestamp estimation of 
   the packet it requests. 
NEW

   ...

   To increase the robustness to the loss of a NACK or of a 
   retransmission packet, a receiver may send a new NACK for the same 
   packet.  This is referred to as multiple retransmissions.  Before 
   sending a new NACK for a missing packet, the receiver should rely 
   on a timer to be reasonably sure that the previous retransmission 
   attempt has failed in order to avoid unnecessary retransmissions. 
    
   NACKs MUST be sent only for the original RTP stream.  Otherwise, 
   if a receiver wanted to perform multiple retransmissions by 
   sending a NACK in the retransmission stream, it would not be able 
   to know the original sequence number and a timestamp estimation of 
   the packet it requests. 

-->Annex A gives some guidelines as to how to dimension the number of 
-->retransmissions.

---
---

NEW  

Annex A How to control the number of retransmissions per packet

Finding out the number of retransmission per packet for achiving the
best possible transmission is a difficult task.  Of course, the absolute
minimum should be one (1) - otherwise, do not use the format.  However,
as of today, the authors are not aware of any studies on the number of
retransmissions per packet, that users of the retransmission format
should set for best performance.  To help implementers and researchers
on this item, this section describes an estimate of the buffering time
required for a given number of retransmissions.  Once the time has been
calculated, it can be communicated to the client via SDP parameter
"rtx-time", as defined in this document.

Scenario and Assumptions
========================
* Streaming scenario with relaxed delay bounds.  Client and server are
provided with buffering space as indicated by the parameter "rtx-time"
in SDP.
* RTP AVPF profile used with SSRC-multiplexing retransmission scheme: 1
SSRC for original packets, 1 for retransmission packets.
* Default RTCP bandwidth share for SRs and RRs, i.e., SR+RR=0.05.  We
have senders (2) and receivers (1). Receivers and senders get equally
1/3 of the RTCP bandwidth share  because the proportion of senders is
greater than 1/4. 
* The profile used is AVPF and Generic NACKs are used for requesting
retransmissions.  This adds 16 bytes of overhead for 1 NACK and 4 bytes
more for every additional NACK FCI field [AVPF]. 
* We assume a worst-case scenario in which each packet exhausts its
corresponding number of available retransmissions, N, before it is
received.  This means that if a packet may be requested for
retransmission a maximum of 2 times, the corresponding generic NACK
report block requesting that particular packet is sent in two
consecutive RTCP compounds; likewise, if it is requested for
retransmission 10 times, then the generic NACK is sent 10 times.  This
assumption makes the RTCP packet size approx. constant after
N*RTCP_intervals (seconds), namely to avg_rtcp_size= 125 + (receiver
RTCP bw share)*(12 + 4*N).  In our case, the receiver RTCP bandwidth
share is 1/3, thus avg_rtcp_size = 129 + 4*N/3.
* Two delay parameters are difficult to approximate and maybe
implementation-dependent.  Therefore, we list them here explicitly
without assigning them a particular value: one is the packet loss
detection time (T2) and the other feedback processing and queueing time
for retransmissions (T5).  Implementers shall assign appropriate values
to these two parameters .

Graphically:

DL : downlink
UL : uplink

Time unit is seconds, s. 
Bitrate unit is bit per second, bps.

DL transmission time            : T1= physical_delay_DL + tx_delay_DL
(=avg_pkt_size/DL_bitrate) + interarrival_delay_jitter
Time to detect packet loss      : T2= pkt_loss_detect_time
Time to report packet loss      : T3= time_to_next_rtcp_report 
UL transmission time            : T4= physical_delay_UL +
transmission_delay_UL + interarrival_delay_jitter 
Retransmissions processing time : T5= feedback_processing_time +
rtx_queuing_time

        Sender
      +-+---------------------------------^-----\-----------------
       \ \                               /       \
        \ \                             |         |
  SN=0   \ \ SN=1                       /         \  RTX(SN=0)
          \ \                          /           \
           X \                        /             \
              `.                     /               \
                \                   /                 \
                 \                 |                   |
                  \                /                   \    ......
                   \              /                     \
      -------------V----D--------/-----------------------V--------
             T1      T2    T3         T4    T5     T1   ........
       Receiver
Goal
====
To find an estimate of the buffering time, T(), that a streaming server
shall use in order to enable a given number of retransmissions for each
packet, N.  This time is approximately equal at the server and at the
client, if one considers that the client starts buffering T1 seconds
later.  

Solution
========
First we find the value of the estimate for 1 retransmission, T(1)=T:

  T = T1 + T2 + T3 + T4 + T5 

Since T1+T4 ~= RTT,

  T = RTT + T2 + T3 + T5 

The worst case for T3 would be that we assume that reporting has to wait
a whole RTCP interval and that the maximum randomization factor of 1.5
is applied.  Therefore, after applying the subsequent compensation to
avoid traffic bursts (see Section A.7 [RTP]), we have that T3 =
1.5/1.21828*RTCP_Interval. Thus,

  T = RTT + 1.2312*RTCP_Interval + T2 + T5

On the other hand, RTCP_Interval = avg_rtcp_size*8*(senders +
receivers)/(RR+RS).  In this scenario: sender + receivers = 3; RR+RS is
the receiver report plus sender report bandwidth share, in this case,
equal to the default 5% of session bandwidth, bw.  We assume an average
RTCP packet size, avg_rtcp_size=125 bytes.  Thus:

  T = RTT + 1.2312*avg_rtcp_size*8*3/(0.05*bw) + T2 + T5

for 1 retransmission.  Thus for enabling N retransmissions, the
available buffering time in a streaming server or client is
approximately:

  T(N) = N*(RTT+1.2312*avg_rtcp_size*8*3/(0.05*bw) + T2 + T5)

As mentioned above, avg_rtcp_size = 125 + (receiver RTCP bw
share=1/3)*(12 + 4*N) = 129 + 4*N/3.  

Numbers
========
If we ignore the effect of T2 and T5, i.e., assume all losses are
detected immediately and there is no additional delay due to feedback
processing or retransmission queueing, we have the following buffering
times for different values of N:

RTCP w/ several Generic NACKs; variable packet size

RTP BW    RTT             N
                 1     2     7     10
64000     0.05  1.25  2.53  9.29  13.64
128000    0.05  0.65  1.32  4.82   7.07
256000    0.05  0.35  0.71  2.59   3.79
512000    0.05  0.20  0.40  1.47   2.14
1024000   0.05  0.13  0.25  0.91   1.32
5000000   0.05  0.07  0.13  0.46   0.67
10000000  0.05  0.06  0.12  0.41   0.58
				
64000	    0.2  1.40  2.83 10.34  15.14
128000    0.2  0.80  1.62  5.87   8.57
256000    0.2  0.50  1.01  3.64   5.29
512000    0.2  0.35  0.70  2.52   3.64
1024000   0.2  0.28  0.55  1.96   2.82
5000000   0.2  0.22  0.43  1.51   2.17
10000000  0.2  0.21  0.42  1.46   2.08
				
64000	     1   2.20  4.43 15.94  23.14
128000     1   1.60  3.22 11.47  16.57
256000     1   1.30  2.61  9.24  13.29
512000     1   1.15  2.30  8.12  11.64
1024000    1   1.08  2.15  7.56  10.82
5000000    1   1.02  2.03  7.11  10.17
10000000   1   1.01  2.02  7.06  10.08

To quantify the error of not taking the Generic NACKS into account, we
can do the same numbers, but ignoring the Generic NACK contribution,
avg_rtcp_size ~= 125 bytes. As we see from below, this may result in a
buffer estimation error of 1-1.5 seconds (5-10%) for lower bandwidth
values and higher number of retransmissions.  This effect is low, but it
may increase if the receiver has a higher bandwidth share.  This should
be carefully evaluated for the particular case; that is way the formula
includes it.

RTCP w/o Generic NACK, fixed packet size ~= 125 bytes
RTP BW    RTT                N
                    1      2    7     10 
64000	   0.05	1.20  2.41  8.43 12.04
128000   0.05	0.63  1.25  4.39  6.27
256000   0.05	0.34  0.68  2.37  3.39
512000   0.05	0.19  0.39  1.36  1.94
1024000  0.05	0.12  0.24  0.85  1.22
5000000  0.05	0.06  0.13  0.45  0.65
10000000 0.05	0.06  0.11  0.40  0.57
			
64000	   0.20	1.35  2.71  9.48 13.54
128000   0.20	0.78  1.55  5.44  7.77
256000   0.20	0.49  0.98  3.42  4.89
512000   0.20	0.34  0.69  2.41  3.44
1024000  0.20	0.27  0.54  1.90  2.72
5000000  0.20	0.21  0.43  1.50  2.15
10000000 0.20	0.21  0.41  1.45  2.07
				
64000	   1.00	2.15  4.31 15.08 21.54
128000   1.00	1.58  3.15 11.04 15.77
256000   1.00	1.29  2.58  9.02 12.89
512000   1.00	1.14  2.29  8.01 11.44
1024000  1.00	1.07  2.14  7.50 10.72
5000000  1.00	1.01  2.03  7.10 10.15
10000000 1.00	1.01  2.01  7.05 10.07

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Aug 2005 13:55:41 +0200

> avg_rtcp_size would be around 125 bytes.  Is this based on your

125 bytes is a figure I use for correctly formed RTCP with CNAME strings 
but still almost minimal assuming no extra blocks than NACKs. If one 
actually uses more information then this figure is of course larger. I 
think it is a reasonable lower size of the RTCP packet even if smaller 
is possible.

Example

  40 IPv6
   8 UDP
  32 Receiver Report with 1 report block
  29 SDES: CNAME (23 chars CNAME string)
  16 FB: NACK
====
125

 From the above it becomes obvious that shorter packets are definitely 
smaller, but I don't see that any packet below 100 bytes are really 
useful in the discussed scenario and I think there are a couple of other 
configurations that also end up in around 125 bytes. For example the 
streaming case with retransmission with SSRC multiplexing which becomes:

  20 IPv4
   8 UDP
  56 Receiver Report with 2 report block (Primary and RTX SSRC)
  29 SDES: CNAME (23 chars CNAME string)
  16 FB: NACK
====
129

A Sender packet is only 4 bytes smaller than the above due to the SR + 1 
report block.

Thus I feel it is a reasonable number, but definitely not the only one 
one can use.

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]

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Aug 2005 16:30:51 +0200

Hi,

See inline for some proposals for changes. Also based on the size of 
changes I would propose that they are done submitting a new draft 
version. Primarily due to the need to provide layout for the new text.

However that SHALL NOT be done until after we have AD agreement on the 
changes.

> Looking forward to your feedback,

   as of the day of publication, the authors where not aware

> "rtx-time", as defined in this document.
DL : downlink (Server -> Client)

> UL : uplink

UL: uplink (Clinet -> Server)

> Retransmissions processing time : T5= feedback_processing_time +

I think one should clarify that this is an reasonable lower end 
avg_rtcp_size but that values appplicable to the situation and 
application should be considered.

> RTCP w/ several Generic NACKs; variable packet size

"why" instead of "way"

> includes it.

Alignment issues for both tables.

> RTCP w/o Generic NACK, fixed packet size ~= 125 bytes

With some updates I think the text do provide a reasonable discussion on 
what one can expect in delay for retransmissions. Please update it and 
send it to the list and Mark Townsley and Allison to see if it adresses 
the discuss.

Cheers

Magnus Westerlund