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

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 22 Jun 2005 10:44:52 -0400

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

- 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