[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] IESG comments on draft-ietf-avr-rtp-retransmission-11.txt: congestion control and retransmission request issuing concerns
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é
> >
> > "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.
> >
> > "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."
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.
[]
> >
> > 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."
> >
OLD:
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.
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 :)
> > "> 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?
> >
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.
[]
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt