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

Hi Magnus,

> Hi Jose,
> 
> I seem to have lost track of the actual question. Was it 
> Marks question in regards to what the minimal required 
> buffering for N possible retransmissions as server side?
> 
His first question was what is the minimum number of retransmissions that should be attempted for a packet. A safe answer to that was one, otherwise don't do RTX.  My suggestion was then to derive a simple estimate for implementors as to what could be the order of magnitude of the buffering time, to which he said it would useful.

> I think you have made some errors in the calculations that 
> are quite important. First of all I think that setting the 
> RTCP_Interval and RTT to the same value is not really valid. 

Yeah, the simplification is not correct.  I agree with your numbers below.

[snip]

> 
> Thirdly I think the worst case wait for the next regular 
> transmission is 1.5*RTCP_Interval/1.21828. One can't ignore 
> the randomization factor in this case as there can be 
> requests that ends up being delayed the maximum time, not the 
> average one.
>
Good point.

> In addition I think the consideration must be done for 
> different RTTs. 
> Both a very short one like 5 ms and much longer ones (1s) to 
> ensure that RTT is correctly taken into consideration.
> 
> Regarding T4, the processing time on the server side. I think 
> that should actually  be included in the formula as it is 
> something that is implementation dependent. It is also a 
> factor when one uses transmission scheduling of any type. 
> Thus I think it should be consider to be maintained as a 
> variable that has no given value.
> 
OK

> Also I would like to introduce a T5 which is the client loss 
> detection time:

OK

[snip]
> 
> T=T1+T2+T3+T4+T5; T1+T3 ~= RTT
> T=RTT + T2 + T4 +T5; T2 = 1.5/1.21828*RTCP_Interval T=RTT + 
> 1.2312*RTCP_Interval + T4 + T5;
> 
> RTCP_Interval = AVG_RTCP_SIZE * 8*(Senders + Receivers) / 
> (RR+RS); In the considered deployment the Sender + Receivers 
> = 3; RR+RS is then equal to 5% of Session BW; AVG_RTCP_SIZE = 
> 125 Thus T=RTT+ 1.2312*AVG_RTCP_SIZE * 8 * 3 /(0.05*BW) + T4+T5
> 
> T(N) = N*(RTT+1.2312*AVG_RTCP_SIZE * 8 * 3 /(0.05*BW)+T4+T5)
> 
> 
> As both T4 and T5 are difficult to give specific values for I 
> have set them equal to zero which results in underestimated values.
> 
> BW       RTT     AVG_RTCP_SIZE  N=1             N=2
> 64000    0,05    125            1,20425         2,4085
> 128000   0,05    125            0,627125        1,25425
> 256000   0,05    125            0,3385625       0,677125
> 512000   0,05    125            0,19428125      0,3885625
> 1024000  0,05    125            0,122140625     0,24428125
> 5000000  0,05    125            0,0647744       0,1295488
> 10000000 0,05    125            0,0573872       0,1147744
> 
> 
> BW       RTT     AVG_RTCP_SIZE  N=1             N=2
> 64000    0,2     125            1,35425         2,7085
> 128000   0,2     125            0,777125        1,55425
> 256000   0,2     125            0,4885625       0,977125
> 512000   0,2     125            0,34428125      0,6885625
> 1024000  0,2     125            0,272140625     0,54428125
> 5000000  0,2     125            0,2147744       0,4295488
> 10000000 0,2     125            0,2073872       0,4147744
> 
> 
> BW       RTT     AVG_RTCP_SIZE   1              2
> 64000    1       125            2,15425         4,3085
> 128000   1       125            1,577125        3,15425
> 256000   1       125            1,2885625       2,577125
> 512000   1       125            1,14428125      2,2885625
> 1024000  1       125            1,072140625     2,14428125
> 5000000  1       125            1,0147744       2,0295488
> 10000000 1       125            1,0073872       2,0147744
> 
[snip]

> So should we try to improve my formula and provide some 
> guiding numbers for certain of the variables? I think it 
> might be worth reconsider the used AVG_RTCP_SIZE to a 
> slightly bigger number, due to that I haven't fully taken the 
> NACK vector into account.

Adding the NACK overhead would be good. What I thought is that we should assume 1) the RTP packet rate is so high that every RTCP_interval you need an additional NACK block and 2) that all lost packets exhaust their available number of retransmissions.  That would be the worstcase assumed.  This would mean that after N*RTCP_interval the average packet size would be 125 + (12 + 4*N) bytes. 

In practice, applied to the numbers above, it means that not taking the NACK packets into account may result in a buffer estimation error of 2-5 seconds depending how many retransmissions.

w/ NACKs
RTP BW      	1    2	7    10
64000	    0.05  1.3   2.78  11.02  16.84
128000    0.05  0.70  1.44  5.68   8.67
256000    0.05  0.38  0.77  3.02   4.59
512000    0.05  0.21  0.43  1.68   2.54
1024000   0.05  0.13  0.27  1.02   1.52
5000000   0.05  0.07  0.13  0.49   0.71
10000000  0.05  0.06  0.12  0.42   0.60

64000	    0.2   1.50  3.08  12.07 18.34
128000    0.2   0.85  1.74  6.73  10.17
256000    0.2   0.53  1.07  4.07  6.09
512000    0.2   0.36  0.73  2.73  4.04
1024000   0.2   0.28  0.57  2.07  3.02
5000000   0.2   0.22  0.43  1.54  2.21
10000000  0.2   0.21  0.42  1.47  2.10

64000       1   2.30  4.68  17.67 26.34
128000      1   1.65  3.34  12.33 18.17
256000      1   1.33  2.67  9.67  14.09
512000      1   1.16  2.33  8.33  12.04
1024000	1   1.08  2.17  7.67  11.02
5000000	1   1.02  2.03  7.14  10.21
10000000	1   1.01  2.02  7.07  10.10

w/o NACKs

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.2  1.35	2.71  9.48	13.54
128000  	0.2  0.78	1.55  5.44	7.77
256000  	0.2  0.49	0.98  3.42	4.89
512000  	0.2  0.34	0.69  2.41	3.44
1024000 	0.2  0.27	0.54  1.90	2.72
5000000 	0.2  0.21	0.43  1.50	2.15
10000000	0.2  0.21	0.41  1.45	2.07

64000	    	1    2.15	4.31  15.08	21.54
128000	1    1.58	3.15  11.04	15.77
256000	1    1.29	2.58  9.02	12.89
512000	1    1.14	2.29  8.01	11.44
1024000	1    1.07	2.14  7.50	10.72
5000000	1    1.01	2.03  7.10	10.15
10000000	1    1.01	2.01  7.05	10.07

So, I think we should add it, at least to have it said that it may become important for multiple retransmissions...

> 
> Then the T4 and T5 values should probably be considered 
> further. The unfortunate thing is that T5 is really 
> problematic and highly variable. 
> In fact it needs an adoptive mechanism to talk this correctly 
> into account. The jitter can be highly variable.
> 

OK we leave them in the formula.

T(N) = N*(RTT+1.2312*AVG_RTCP_SIZE * 8 * 3 /(0.05*BW)+T4+T5); where AVG_RTCP_SIZE= 125 + 12 + 4*N bytes,  if we account for General NACKs

Cheers,

José

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt