RE: [AVT] IESG comments on draft-ietf-avr-rtp-retransmission-11.txt- Issue 4: more parameters needed for RTX?

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

Hi Mark,

We have been discussing this algorithm in the WG: it is for finding out the required buffering time for packets in order to allow for a number N of retransmissions.  As we discussed previously, there is no studies regarding what should be the recommended value of retransmissions, but at least such an buffering time estimate will help in finding that out. 

Attached is proposed changes to the draft.  Please comment so I can include this in a new revision and last-call it.

Cheers,
José

---
---
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 achieving 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 date of publication, the authors were 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 of session members.

* avg_rtcp_size is approximated by 120 bytes.  This is a rounded-up average of 2 SRs, one for each SSRC, containing 40/8/28/32 bytes for IPv6/UDP/SR/SDES with CNAME, thus making 105 bytes each; and a RR with 40/8/64/32 bytes for IPv6/UDP/2*RR/SDES, making 157 bytes, thus (157+105+105)/3=117,3~=120 bytes.  The important of this value is that it is something over 100 bytes, which seems to be a representative figure for typical configurations.

* 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= 120 + (receiver_RTCP_bw_share)*(12 + 4*N).  In our case, the receiver RTCP bandwidth share is 1/3, thus avg_rtcp_size = 124 + 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 (client->server)
UL : uplink (server->client)

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=120 bytes.  This includes  Thus:

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

for 1 retransmission.  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 per above, avg_rtcp_size = 120 + (receiver_RTCP_bw_share=1/3)*(12 + 4*N) = 124 + 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= 124 + 4*N/3 bytes
                         N value
RTP BW	 RTT	1,00	2,00	5,00	7,00	10,00
64000	 	 0,05	1,21	2,44	6,28	8,97	13,18
128000	 0,05	0,63	1,27	3,27	4,66	6,84
256000	 0,05	0,34	0,68	1,76	2,50	3,67
512000	 0,05	0,19	0,39	1,00	1,43	2,09
1024000	 0,05	0,12	0,25	0,63	0,89	1,29
5000000	 0,05	0,06	0,13	0,33	0,46	0,66
10000000     0,05	0,06	0,11	0,29	0,41	0,58
						
64000	 	 0,2	1,36	2,74	7,03	10,02	14,68
128000	 0,2	0,78	1,57	4,02	5,71	8,34
256000	 0,2	0,49	0,98	2,51	3,55	5,17
512000	 0,2	0,34	0,69	1,75	2,48	3,59
1024000	 0,2	0,27	0,55	1,38	1,94	2,79
5000000	 0,2	0,21	0,43	1,08	1,51	2,16
10000000 	 0,2	0,21	0,41	1,04	1,46	2,08
						
64000	 	 1	2,16	4,34	11,03	15,62	22,68
128000	 1	1,58	3,17	8,02	11,31	16,34
256000	 1	1,29	2,58	6,51	9,15	13,17
512000	 1	1,14	2,29	5,75	8,08	11,59
1024000	 1	1,07	2,15	5,38	7,54	10,79
5000000	 1	1,01	2,03	5,08	7,11	10,16
10000000 	 1	1,01	2,01	5,04	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 ~= 120 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 in this case.  Nevertheless, it should be carefully evaluated for the particular scenario; that is why the formula includes it.

RTCP w/o Generic NACK, fixed packet size ~= 120 bytes
                         N value
RTP BW	 RTT	1,00	2,00	5,00	7,00	10,00	
64000	 	 0,05	1,16	2,32	5,79	8,11	11,58
128000	 0,05	0,60	1,21	3,02	4,23	6,04
256000	 0,05	0,33	0,65	1,64	2,29	3,27
512000	 0,05	0,19	0,38	0,94	1,32	1,89
1024000	 0,05	0,12	0,24	0,60	0,83	1,19
5000000	 0,05	0,06	0,13	0,32	0,45	0,64
10000000 	 0,05	0,06	0,11	0,29	0,40	0,57
						
64000	 	 0,2	1,31	2,62	6,54	9,16	13,08
128000	 0,2	0,75	1,51	3,77	5,28	7,54
256000	 0,2	0,48	0,95	2,39	3,34	4,77
512000	 0,2	0,34	0,68	1,69	2,37	3,39
1024000	 0,2	0,27	0,54	1,35	1,88	2,69
5000000	 0,2	0,21	0,43	1,07	1,50	2,14
10000000 	 0,2	0,21	0,41	1,04	1,45	2,07
						
64000	 	 1	2,11	4,22	10,54	14,76	21,08
128000	 1	1,55	3,11	7,77	10,88	15,54
256000	 1	1,28	2,55	6,39	8,94	12,77
512000	 1	1,14	2,28	5,69	7,97	11,39
1024000	 1	1,07	2,14	5,35	7,48	10,69
5000000	 1	1,01	2,03	5,07	7,10	10,14
10000000     1	1,01	2,01	5,04	7,05	10,07 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of W. Mark Townsley
> Sent: Sonntag, 26. Juni 2005 12:54
> To: Jose Rey
> Cc: Magnus Westerlund; IETF AVT WG; Colin Perkins; TSV ADs; 
> [e-mail]
> Subject: Re: [AVT] IESG comments on 
> draft-ietf-avr-rtp-retransmission-11.txt- Issue 4: more 
> parameters needed for RTX?
> 
> 
> 
> Jose Rey wrote:
> 
> >  
> > 
> > 
> >>-----Original Message-----
> >>From: W. Mark Townsley [mailto:[e-mail]]
> >>Sent: Wednesday, June 22, 2005 4:45 PM
> >>To: Jose Rey
> >>Cc: TSV ADs; Magnus Westerlund; Colin Perkins; 
> [e-mail]; 
> >>IETF AVT WG
> >>Subject: Re: [AVT] IESG comments on
> >>draft-ietf-avr-rtp-retransmission-11.txt - Issue 4: more parameters 
> >>needed for RTX?
> >>
> >>
> >>
> >>Jose Rey wrote:
> >>
> >>
> >>>Hi Mark, all,
> >>>
> >>>You say:
> >>>
> >>>"What I am afraid of in a few cases here is that if someone
> >>
> >>is handed
> >>
> >>>this document code from without a reference implementation
> >>
> >>to go by,
> >>
> >>>some of the lack of details in these sections would end up in: (1) 
> >>>several questions posted to a list asking for help, (2) a lot of 
> >>>guesses made, or (3) an unusable number of configuration
> >>
> >>commands to
> >>
> >>>tweak each and every possible parameter."
> >>>
> >>>==>Yes, the client/server has limited means to set certain
> >>
> >>parameters
> >>
> >>>that may help in defining when / how to use RTX.  There is 
> just one 
> >>>parameter defined on this regard and that would be the
> >>
> >>server buffer
> >>
> >>>time, "rtx", which specifies the time a server keeps the
> >>
> >>packet in its
> >>
> >>>buffers.  One could add additional parameters, i.e.,
> >>
> >>parameter(s) that:
> >>
> >>>1) allow server to tell the receiver qualitative how to use
> >>
> >>NACKs, e.g.:
> >>
> >>>a) minimum / maximum number of retransmissions per packet; b) what 
> >>>timer value to use for the retransmission requests; c) etc...or,
> >>>2) allow the server to do the same in a more detailed form, e.g.:
> >>>bitrate share that should be allocated to the
> >>
> >>retransmission stream,
> >>
> >>>number of packets that should be reported in each NACK compound et 
> >>>cetera.
> >>>
> >>>On the other hand, these settings may sometimes be dynamic 
> and even 
> >>>not apply to all packets equally, so it would be very
> >>
> >>difficult to express
> >>
> >>>them in, say, SDP.   Like the number of rtxs per packet 
> >>
> >>depends on how
> >>
> >>>important it is. Also O/A would be needed... 
> >>>
> >>>I think that this is too detailed and complex; using the RTCP 
> >>>bandwidth modifiers (RFC3556) should enable to play with these 
> >>>settings at a fraction of the complexity.  Therefore I
> >>
> >>would leave it
> >>
> >>>as is and include the following text in the draft section 6.3 
> >>>"Retransmission requests" :
> >>>
> >>>"The server may indirectly control the number of retransmission 
> >>>requests per packet by specifying the RTCP bandwidth of the
> >>
> >>original
> >>
> >>>RTP stream, e.g., by using the RTCP bandwidth modifiers as
> >>
> >>per RFC 3556 [ref].
> >>
> >>>Although this is an approximate approach, it is preferred
> >>
> >>to defining
> >>
> >>>parameters for each type of appplication because it is 
> simpler.  If 
> >>>actual experience proves this not to be sufficient, more detailed 
> >>>parameters shall be defined in the future."
> >>>
> >>>Comments?
> >>
> >>This still sounds like a big dose of handwaving to me. Can 
> you not at 
> >>least include some min/max here so you are sure that 
> packets don't get 
> >>lost? A recommended default that would at least *work* and 
> not cause 
> >>lost packets? Sure, leave room for optimization based on bandwidth 
> >>modifiers, specific configuration, etc. but I'm afraid that 
> without a 
> >>starting point or specific algorithm you could end up with widely 
> >>variant choices here from future implementations (unless, 
> as I said, 
> >>people just go figure out what vendor x does and copy it, in which 
> >>case it should have just been in the spec).
> >>
> > 
> > 
> > Of course, the minimum is one. For enabling at least one 
> rtx per packet, the server is only required to save it for 
> some period of time.  This time has several components:
> > 
> > 1- the time that the client takes to notice the loss.  For 
> single tone losses this is when the next packet comes (taking 
> out reordering buffer now), that is the intearrivel jitter plus
> > 2- the time it has to wait until the next RTCP send time, 
> which is ~1/2*RTCP interval if we assume uniform 
> distribution,which is common plus
> > 3- the time it takes for the server to process rtx request 
> (ignore it?)
> > 4- 1 RTT to account for the initial (failed) tx and the 
> time it takes for the rtx packet to the client
> > 
> > For more than 1, just multiply.  
> > 
> > This is a rough & quick analysis using common sense but I 
> haven't experimented with this. For bursty losses this is 
> more complex, of course (term 2 is complex).  Reordering is a 
> fixed delay, more or less.
> > 
> > The maximum can be calculated in the same way by using up 
> the available buffer.  
> > 
> > For the time being, one could make a table with link 
> bandwidths, typical RTTs and what the buffer amount should be 
> as f(RTT) for different RTCP bws, at least for the default 
> 5%.  As well as for the maximum rtxs that the buffer allows.
> > 
> > Does this make sense?
> 
> Yes, it is at least something for an implementation to go by. 
> Since you mention 
> that you haven't experimented with this, I assume there is not much 
> implementation of such a method? I was hoping that there were some 
> implementations to try and document here rather than 
> designing on the fly based 
> on my comments. If this is brand new, perhaps you could pass 
> the table and 
> algorithm by the WG in a separate thread to see if there is 
> consensus for it.
> 
> Thanks,
> 
> - Mark
> 
> > 
> > José
> > 
> >  
> > 
> > 
> >>- Mark
> >>
> >>
> >>>---------------------------------------------
> >>>Jose Rey     mailto:[e-mail]
> >>>P R D C G - Panasonic R&D Center Germany GmbH
> >>>Phone/Fax: [phone]/166
> >>>--------------------------------------------- 
> >>>
> >>>
> >>>_______________________________________________
> >>>Audio/Video Transport Working Group
> >>>[e-mail]
> >>>https://www1.ietf.org/mailman/listinfo/avt
> >>>
> >>
> >>
> > 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
> 
> 


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