On 03/06/2012 12:32 AM, Colin Perkins wrote: 
Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution.

Colin



Begin forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
Date: 5 March 2012 20:17:59 GMT
To: i-d-announce@ietf.org
Reply-To: internet-drafts@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : RTP Congestion Control: Circuit Breakers for Unicast Sessions
	Author(s)       : Colin Perkins
                         Varun Singh
	Filename        : draft-perkins-avtcore-rtp-circuit-breakers-00.txt
	Pages           : 14
	Date            : 2012-03-05

  The Real-time Transport Protocol (RTP) is widely used for telephony,
  video conferencing, and telepresence applications.  These
  applications are often used over best-effort UDP/IP networks.  If
  congestion control is not implemented then network congestion will
  deteriorate the user's multimedia experience.  This document does not
  propose a congestion control algorithm.  Instead, it specifies a
  minimal set of "circuit-breakers".  Circuit-breakers are conditions
  under which an RTP flow should cease to transmit 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.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breakers-00.txt


    

    Thanks for this work!

    

    A few questions (to make sure I get them noted down):

    

    Section 4.1:

    

    
    
   Accordingly, if a
   sender of RTP data packets receives two or more consecutive RTCP RR
   packets from the same receiver that correspond to its transmission
   and have a non-increasing extended highest sequence number received
   field, then that sender SHOULD cease transmission.



    If I see RTCP packets with

    

    1: highest sequence number = 2

    2: highest sequence number = 2

    3: highest sequence number = 2

    

    do I cease transmission after packet 3 has arrived, or after packet
    2 has arrived?

    I *think* the logical time is after packet 3 has arrived, but I'm a
    little unsure that the words are

    unambiguously saying that; it's not 100% clear to me whether packet
    1 is considered included in the set of "non-increasing highest
    sequence number".

    

    Section 4.2: Is it reasonable to replace, for the purposes of this
    calculation, "an order of magnitude" with "a factor of ten"? (for
    those who don't have a physics background, putting text somewhere
    that says that an order of magnitude is "somewhere around a factor
    of ten" might be appropriate.)

    

    We might also want to add the words about doing a dramatically
    reduced rate if we can from section 4.1 here, factor it out as a
    general statement, or say that it is not appropriate here if it's
    not.

    

    Security considerations (missing section): For an end node that
    implements this specification, an active attacker can cut the
    transmission by faking two RTCP packets that get accepted instead of
    the recipient's RTCP packets. This may be worthy of a note, and
    pointer to appropriate defenses.

    

    Good stuff!

    

                         Harald