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?)

["Jose Rey" <[e-mail]>]

 

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:[e-mail]
P R D C G - Panasonic R&D Center Germany GmbH
Phone/Fax: [phone]/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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt