Subject: Re: [AVT] IESG comments on draft-ietf-avr-rtp-retransmission-11.txt: congestion control and retransmission request issuing concerns

From: Colin Perkins <[email-masked]>
Date: Mon, 2 May 2005 11:15:18 +0100

Jon: We'd like to move forward with this: could you please review the 
changes to see if they address your concerns?

Jose: could you please prepare a list of changes to the draft, giving 
old and new text? This would make it easier to see what has changed.

Colin

On 20 Apr 2005, at 16:10, Jose Rey wrote:
> (first of all, I apologize for the delay)
>
> Hi,
>
> This email has two parts as per subject.  The only unanswered comment 
> is one on the reference implementation from Mark.  David may have 
> something to say there but since he's travelling now he hasn't found 
> the time yet.
>
> Wrt the CC comments,
>
> Jon says:
> 	
> "In the first place, we do not make a practice of passing Proposed 
> Standard congestion control systems which lack sufficient 
> implementation experience. It is more common for such mechanisms to 
> spend considerable time as Experimental RFCs before we consider them 
> for PS. Is there any reason why this document is not going to 
> Experimental now?"
>
> ==>??,  RTX is not a congestion control system, the send rate is 
> determined by a CC mechanism only.  If there are reasons for 
> experimental then not here, no?
>
> "The sorts of statements made in Section 7 seem to provide just cause 
> for caution. The entire section is scoped to a SHOULD, and offers no 
> guidance as to when or why this SHOULD might not apply. The same 
> applies to the other SHOULDs sprinkled through the ensuing paragraphs 
> - if the authors envision a condition like the following:
>
>   If the packet loss rate exceeds an
>   acceptable level, it SHOULD be concluded that congestion is not
>   kept under control and retransmission SHOULD NOT then be used.
>
> ... i.e., in which implementations merely SHOULD NOT ignore evidence 
> of increasing packet loss due to the use of this mechanism, then this 
> specification would be the right place to raise counterexamples; 
> otherwise these normative statements ought to be MUSTs."
>
> ==>A justification for the SHOULD would be, for example, when the 
> stream is paused to let the buffer fill up again as packets are 
> re-sent.  RTX explicitly allows retransmissions to be sent during RTSP 
> PAUSE.  Another example could be application-specific messages (as per 
> AVPF) that could trigger repetition of a particular packet or frame.  
> In this line, another similar example:  when the server estimates a 
> particular requested frame is more important than the rest and sends 
> it in times of congestion ( kind of "receive better this than 
> nothing").  These could be added as examples right behind the text 
> above.
>
> "The second paragraph of Section 7 seems to allude to the congestion 
> control guidance in Section 2 of RFC3551, and the remainder of the 
> section uses this guidance as a yardstick. However, this document 
> offers no concrete advice to implementers on how an application might 
> determine if packet loss is within acceptable limits as those 
> guidelines suggest."
> [Also Mark had similar comments: that little guidance here is a 
> problem when implementing]
>
> ==>Hhmmm..maybe "acceptable packet loss level" is not the right 
> wording.  The "acceptable packet loss level" is an application thing 
> that cannot be specified here.  Such assertions are based on 
> subjective or objective evaluations of application performance.
>
> The whole point is that RTX should not be used when the application is 
> experiencing or recovering from congestion (except as above).  Now, 
> deciding when congestion is "over" is a difficult task that cannot be 
> specified here.  Therefore I would change the text above to:
>
>   "If the congestion is not
>   kept under control, then retransmission SHOULD NOT then be used."
>
> "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."
>
> ==>This is a different issue but related to the above: 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".  If this is not enough, so would it make sense to introduce any 
> of the following additional information as follows in the SDP (or 
> elsewhere)?
>
> I.e. parameter(s) that:
>
> 1) Allow server to tell the receiver *implicitly* how to use NACKs as 
> a collection of parameters, understood as guidance values:  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 explicitly: bitrate share that 
> should be allocated to the retransmission stream, number of packets 
> that should be reported in each RR.
>
> Comments:
> - In all options, the server always decides what is actually 
> retransmitted;
> - In 2) the server has to do most calculations while in in 1) this is 
> done by the client.
>
> *Question* : does it make sense to add this to the SDP of this 
> document? I am not sure if these should be present here or let for 
> experimentation first.
>
> -----------
>
> Wrt to the other comments on "retransmission requests" from Mark:
>
> "6.3 Retransmission requests
>
>>    The receiver should not send a retransmission request as soon as
>>    it detects a missing sequence number but should add some extra
>>    delay to compensate for packet reordering.  This extra delay may,
>>    for example, be based on past observations of the experienced
>>    packet reordering.
>
> If packet reordering is determined to be extremely rare (e.g., 
> essentially never - perhaps due to the underlying datalink preventing 
> misordering) then the optimum delay here could in fact be zero except 
> in the rarest of cases. I'm afraid that an implementor might take this 
> too literally and always include some minimum delay, inhibiting 
> performance for no good reason. Perhaps it should be pointed out that 
> "some delay" may in fact be zero in some cases."
> Also, the best "possible reorder delay" algorithm may not actually be 
> time based, but packet based. e.g., if n number of packets are 
> received after a gap is detected, then assume that the packet was 
> truly lost rather than out of order (something, incidentally, which 
> may be far easier to code on some platforms as a very short fixed FIFO 
> packet buffer rather than via a timer-based mechanism)."
>
>
> ==>Thanks, this is a very helpful comment.  Here is some work out some 
> text on this based taking *much* from your comments.
>
> "It should be noted, in environments where packet reordering is rare 
> or does not take place, e.g., if the underlying datalink layer affords 
> ordered delivery, the delay may be extremely low or even take the 
> value zero.  In such cases, an appropriate "reorder delay" algorithm 
> may not actually be timer-based, but packet-based.  E.g., if n number 
> of packets are received after a gap is detected, then it should be 
> assumed that the packet was truly lost rather than out of order.  This 
> may turn out to be far easier to code on some platforms as a very 
> short fixed FIFO packet buffer as opposed to the timer-based 
> mechanism."
>
> ">    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.
>
> Simply stating "should rely on a timer" doesn't really give the 
> implementor much to go on as to what interval the timer should be set 
> to. Earlier in this section, calculation of an RTT was referenced. 
> Perhaps this RTT should be used as part of the algorithm for when one 
> might send a multiple retransmission NACK request? From this text 
> alone, it isn't obvious what to base this timer on, what the default 
> value might be, whether it should be adaptive, etc."
>
> ==>Yes, the timer should be based in the observed RTT.  For a start, I 
> would leave it static, since experience is needed to find a meaningful 
> description/value of an adaptive mechanism. BTW, just to check, with 
> "part of the algorithm for when to send multiple retransmissions", I 
> guess you mean some adaptive algorithm that adjusts the timer for each 
> subsequent request?
>
> "Page 13, Section 7, Congestion control.
>
>>    In addition, the sender MAY selectively retransmit only the
>>    packets that it deems important and ignore NACK messages for other
>>    packets in order to limit the bitrate.
>
> I think this could end up creating a situation where one side asks for 
> a packet repeatedly (multiple retransmission NACKs), and the other 
> side ignores the request repeatedly (not sending due to selective 
> retransmission)? Is this considered a reasonable and expected behavior 
> of the protocol?"
>
> ==>Yes, but this is not dangerous. Typically (at leat this is done in 
> 3GPP) the client will report over a fixed number of packets or, in 
> other words, carry fixed number of RTCP NACK reports (adjusted to the 
> RTCP packet size).  Although this client-requesting-server-ignoring 
> can happen a couple of times it doesn't add any danger or overhead 
> since the NACK window simply "moves on"
>
> Looking forward to your comments,
>
> José
>
>> -----Original Message-----
>> From: Colin Perkins [mailto:[email-masked]]
>> Sent: Friday, April 01, 2005 2:57 PM
>> To: Jose Rey; [email-masked]; Akihiro Miyazaki; Rolf
>> Hakenberg; [email-masked]
>> Cc: Magnus Westerlund; Allison Mankin
>> Subject: IESG comments on draft-ietf-avr-rtp-retransmission-11.txt
>>
>> Folks,
>>
>> The IESG has reviewed
>> draft-ietf-avt-rtp-retransmission-11.txt and has a number of
>> significant comments which can be found in the I-D tracker:
>>
>> https://datatracker.ietf.org/public/pidtracker.cgi?
>> command=print_ballot&ballot_id=973&filename=draft-ietf-avt-rtp-
>> retransmission
>>
>> To move forwards, you should review the comments to either
>> propose changes to the draft to address the IESG's concerns
>> or to explain why those concerns are not valid. It has been
>> suggested that one possible route forwards might be to move
>> to draft forward as an experimental RFC, documenting the
>> concerns about congestion control and security, but even that
>> approach would require adding text to document the issues.
>>
>> Opinions?
>>
>> Colin
>>
>>
>>
>
>
> _______________________________________________
> 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: "Jose Rey" <[email-masked]>
Date: Wed, 11 May 2005 11:57:52 +0200

Colin, Jon,

> Jose: could you please prepare a list of changes to the 
> draft, giving old and new text? This would make it easier to 
> see what has changed.

Here is the text I proposed in the last emails in the requested format.  Not all comments are addressed with these new text pieces as I still await guidance from Jon and Mark.

Thanks,

José

> >   kept under control, then retransmission SHOULD NOT then be used."

OLD:
   These congestion control mechanisms should keep the packet loss 
   rate within acceptable parameters.  Packet loss is considered 
   acceptable if a TCP flow across the same network path and 
   experiencing the same network conditions would achieve, on a 
   reasonable timescale, an average throughput, that is not less than 
   the one the RTP flow achieves.  If the packet loss rate exceeds an 
   acceptable level, it SHOULD be concluded that congestion is not 
   kept under control and retransmission SHOULD NOT then be used.  It 
   may further be necessary to adapt the transmission rate (or the 
   number of layers subscribed for a layered multicast session), or 
   to arrange for the receiver to leave the session.  

NEW:

   These congestion control mechanisms should keep the packet loss 
   rate within acceptable parameters.  In the context of congestion control, packet loss is considered 
   acceptable if a TCP flow across the same network path and 
   experiencing the same network conditions would achieve, on a 
   reasonable timescale, an average throughput, that is not less than 
   the one the RTP flow achieves.  If congestion is not
   kept under control, then retransmission SHOULD NOT be used.  

   Retransmissions MAY still be sent in some cases, e.g., 
   in wireless links where packet losses are not caused by congestion, or if the 
   server (or the client that makes the retransmission request) estimates that a particular
   packet or frame is important to continue play out, or if an RTSP PAUSE has been 
   issued to allow the buffer to fill up (RTSP PAUSE does not affect
   the sending of retransmissions.)  

   Finally, it may further be necessary to adapt the transmission rate (or the 
   number of layers subscribed for a layered multicast session), or 
   to arrange for the receiver to leave the session.  

[]

> > short fixed FIFO packet buffer as opposed to the timer-based 
OLD:

NEW:

   The receiver should not send a retransmission request as soon as 
   it detects a missing sequence number but should add some extra 
   delay to compensate for packet reordering.  This extra delay may, 
   for example, be based on past observations of the experienced 
   packet reordering.  It should be noted that, in environments where
   packet reordering is rare or does not take place, e. g., if the 
   underlying datalink layer affords ordered delivery, the delay may 
   be extremely low or even take the value zero. In such cases, an 
   appropriate "reorder delay" algorithm may not actually be 
   timer-based, but packet-based. E. g., if n number of packets are
   received after a gap is detected, then it should be assumed 
   that the packet was truly lost rather than out of order. This may 
   turn out to be far easier to code on some platforms as a very 
   short fixed FIFO packet buffer as opposed to the timer-based mechanism.

(I shamelessly lent much of the new text from Mark :)

> > guess you mean some adaptive algorithm that adjusts the 
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 to avoid unnecessary retransmissions. 

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 and so avoid unnecessary retransmissions.  
   The timer value shall be based on the observed round-trip time.  Both, a static
   or an adaptive value MAY be used.  

   An adaptive timer could be one that changes its value with 
   every new request for the same packet.  This document 
   does not provide any guidelines as to how this adaptive value should
   be calculated because no experiments have been done to find this out.

[]