Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-01.txt

[Kevin Gross <[e-mail]>]

Comments on this draft. Some I mentioned in the session today. Smaller ones
I did not.

Abrstract:

Contains the phrase "is expected to stop transmitting." We probably want to
make a stronger statement here. Normative text in the draft uses "MUST".

Suggest untangling and clarifying this sentence:

Old: "It is expected that all RTP

   applications running on best-effort networks will be able to run

   without triggering these circuit breakers in normal operation."


New: "It is expected that, in the absence of severe congestion, all RTP

   applications running on best-effort networks will be able to run

   without triggering these circuit breakers."


Section 3:

Explain why multicast sessions are out of scope.


Last bullet point on page 4 mentions that RTCP report interval is dependent
on number of participants in the session. Number of participants in a
unicast session is always 2 so this is not a contribution if multicast is
our of scope.

Add editorial clarification to rapid feedback bullet on page 5:

Old: "The use of the RTP/AVPF profile is dependent
      on signalling, but is otherwise generally backwards compatible, as
      it keeps the same average RTCP reporting interval as the base RTP
      specification."

New: "The use of the RTP/AVPF profile is dependent
      on signalling, but is otherwise generally backwards compatible with
RTP/AVP, as
      it keeps the same average RTCP reporting interval as the base RTP
      specification."


Section 4 point 2: Multiple packets per frame is a problem. Multiple frames
per packet is not a problem:

Old: "...the jitter is only meaningful for RTP

       flows that send a single data packet for each RTP timestamp value

       (i.e., audio flows, or video flows where each frame comprises one

       RTP packet)."


New: "...the jitter is only meaningful for RTP

       flows that send a single data packet for each RTP timestamp value

       (i.e., audio flows, or video flows where each packet comprises
one or more video frames)."


p.7 The following text may need work:


"The remaining congestion signals are the packet loss fraction and the

   cumulative number of packets lost.  These are robust indicators of

   congestion in a network where packet loss is primarily due to queue

   overflows, although less accurate in networks where losses can be

   caused by non-congestive packet corruption.  TCP uses packet loss as

   a congestion signal."


TCP intentionally causes congestion to determine available link bandwidth.
It is using packet loss to measure capacity. In the presence of
TCP characterizing loss fraction as a roust indicator is probably an
overstatement. The interaction probably deserves some
some further investigation.


Section 4.1: Delete second paragraph. As disused in the session today, if
things are messed up enough to trigger circuit breaker #1, reducing offered
load is not likely a useful response. Section 4.3 contains a copy of this
recommendation and is probably an appropriate recommendation for circuit
breaker #3 described there.

"What it means to cease transmission..." text appears three times (4.1, 4.2
and 4.3). It probably should just appear once and be reference three times.

Section 4.1: Specify what a "long time" is:

Old: "...but would lead to problematic flows running for a

   long time before being cut off."


New: "...but would lead to problematic flows running for at least 15
seconds before being cut off."


Section 4.2: As discussed in the session today, this section needs to be
improved to discuss devices that don't implement RTCP. One obvious
improvement is to condition the receiver behavior described at the bottom
of page 9. A receiver should not trip this circuit breaker if it is
receiving RTP packets from the sender.

p.10: The equation has a divide-by-zero hazard. You may want to explicitly
state that the circuit breaker does not trip if the denominator is 0.

Section 4.3: Simulation is required to gain confidence that there are no
false-trigger conditions for this circuit breaker. Test in the presence of
competing TCP flows. Test different RTCP RR reporting delay and packet loss
scenarios. Solicit more ideas from others.

Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org



On Tue, Oct 30, 2012 at 11:05 AM, Colin Perkins <[e-mail]> wrote:

> A summary of the changes in this version is as follows:
>
> - Clarify that multicast congestion control is outside the scope of this
> memo.
>
> - Clarify what it means for an implementation to cease transmission when
> the circuit breaker fires. Specifically, the intention is that the
> application will stop sending RTP data packets until the user makes an
> explicit attempt to restart the call. The draft notes that RTP flows halted
> by the circuit breaker should not be restarted automatically unless the
> sender has received information that the congestion has dissipated.
>
> - Add an explicit RTCP Timeout circuit breaker in Section 4.2 (this is a
> revised and extended version of Section 8 of the -00 draft). Unlike the
> media timeout in Section 4.1, which fires when returning RTCP RR packets
> show that media isn't reaching the receiver, this circuit breaker is
> triggered if RTCP packets are no longer returning to the sender.
>
> - In section 4.3, clarify when high-rate senders can back-off to a lower
> rate when the circuit breaker is triggered, and when they need to cease
> transmission.
>
> - Expand and clarify Section 5 about RTP circuit breakers for systems
> using the RTP/AVPF profile. A sender needs to process early RTCP reports
> that contain an SR/RR packet as-if they were regular RTCP reports, but
> ignore early non-compound RTCP packets without an SR/RR. This allows the
> use of low-overhead early RTP/AVPF feedback without triggering the RTP
> circuit breaker, and so is suitable for RTP congestion control algorithms
> that need to quickly report loss events in between regular RTCP reports.
>
> - Expand and clarify Section 6 about the impact of RTCP XR, to note that
> RTCP XR packets are ignored by the circuit breaker algorithm.
>
> - Expand and clarify Section 7 about the impact of ECN, to note that
> reports of ECN-CE marks are treated as packet loss for the congestion based
> circuit breaker, but ignored for the media timeout and RTCP timeout circuit
> breakers.
>
> - Expand and clarify Section 8 on the security considerations to discuss
> authentication requirements.
>
> I believe this draft is on the agenda for the AVTCORE meeting in Atlanta,
> but feedback via the list is also welcome.
>
> Colin
>
>
>
>
> On 22 Oct 2012, at 23:16, [e-mail] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Audio/Video Transport Core Maintenance
> Working Group of the IETF.
> >
> >       Title           : RTP Congestion Control: Circuit Breakers for
> Unicast Sessions
> >       Author(s)       : Colin Perkins
> >                          Varun Singh
> >       Filename        : draft-ietf-avtcore-rtp-circuit-breakers-01.txt
> >       Pages           : 16
> >       Date            : 2012-10-22
> >
> > Abstract:
> >   The Real-time Transport Protocol (RTP) is widely used in telephony,
> >   video conferencing, and telepresence applications.  Such applications
> >   are often run on best-effort UDP/IP networks.  If congestion control
> >   is not implemented in the applications, then network congestion will
> >   deteriorate the user's multimedia experience.  This document does not
> >   propose a congestion control algorithm; rather, it defines a minimal
> >   set of "circuit-breakers".  Circuit-breakers are conditions under
> >   which an RTP flow is expected to stop transmitting media to protect
> >   the network from excessive congestion.  It is expected that all RTP
> >   applications running on best-effort networks will be able to run
> >   without triggering these circuit breakers in normal operation.  Any
> >   future RTP congestion control specification is expected to operate
> >   within the envelope defined by these circuit breakers.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-01
> >
> > A diff from the previous version is available at:
> >
> http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-circuit-breakers-01
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
>
>
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>