[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] IESG comments on draft-ietf-avr-rtp-retransmission-11.txt: congestion control and retransmission request issuing concerns
(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:csp at csperkins.org]
> Sent: Friday, April 01, 2005 2:57 PM
> To: Jose Rey; Viktor.Varsa at nokia.com; Akihiro Miyazaki; Rolf
> Hakenberg; david.leon at nokia.com
> 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
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt