(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