Subject: 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: Wed, 22 Jun 2005 18:08:43 +0200

> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]] 
> Sent: Wednesday, June 22, 2005 4:45 PM
> To: Jose Rey
> Cc: TSV ADs; Magnus Westerlund; Colin Perkins; 
> [email-masked]; 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?

José

> - Mark
> 
> > 
> > ---------------------------------------------
> > Jose Rey     mailto:[email-masked]
> > P R D C G - Panasonic R&D Center Germany GmbH
> > Phone/Fax: +49(0)6103766-134/166
> > --------------------------------------------- 
> > 
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/avt
> > 
> 
> 

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

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sun, 26 Jun 2005 06:54:12 -0400

> 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…

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