[R-C] Fwd: WG Review: RTP Media Congestion Avoidance Techniques (rmcat)

[Mirja Kuehlewind]

Hi,

I know I'm late to comment, but after reading the charter again, I have to 
admit that two points are not absolutely clear to me. Maybe someone can 
provide further explanations here:

>     - Develop a mechanism for identifying shared bottlenecks between
> groups of flows, and means to flexibly allocate their rates within the
> aggregate hitting the shared bottleneck.
Why do I need to identify shared bottleneck? The task of congestion control is 
to shared the bottleneck capacity in some way. Usually I will end up with a 
different share if the same or a different congestion control algorithm is 
used by the competing flow(s). Is the idea here to detect a shared bottleneck 
and then change the congestion control behavior to achieve a different share 
than I would otherwise? I there a concrete scenario or approach how what to 
do this and why this is needed in case a shared bottleneck is detected? 

>     - Develop techniques to detect, instrument or diagnose failing to
> meet RT schedules due to failures of components outside of the charter
> scope, possibly in collaboration with IPPM.
I believe I got the idea behind this but I not really sure how to realize it. 
Are you expecting some explicit feedback from the receiver (or even other 
components)? Is there a concrete proposal already how to do this? What are 
you planning to do if you have detected an RT schedule failure? Change the 
congestion control in some way (to be more aggressive)?

Thanks for clarification,
Mirja


On Thursday 06 September 2012 04:42:02 Wesley Eddy wrote:
> As you can see, the RMCAT charter is now out for review, and scheduled
> for approval on the next IESG telechat.
>
> The charter below is pretty much just the previous one that Michael sent
> to this list, with tweaks that I made in order to satisfy some of the
> blocking and non-blocking comments that it attracted during the IESG
> internal review.
>
> It does seem to be missing the milestones at the moment; which should
> be no real issue as they mimic the final set of deliverables bullets
> largely.  However, I think this is an issue with our new chartering
> tool that RMCAT is making the first real use of, and I'll work to
> resolve it with the tool.
>
>
> -------- Original Message --------
> Subject: WG Review: RTP Media Congestion Avoidance Techniques (rmcat)
> Date: Wed, 05 Sep 2012 14:46:52 -0700
> From: The IESG <iesg-secretary at ietf.org>
> To: IETF-Announce <ietf-announce at ietf.org>
>
> A new IETF working group has been proposed in the Transport Area. The
> IESG has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2012-09-12.
>
> RTP Media Congestion Avoidance Techniques (rmcat)
> ------------------------------------------------
> Current Status: Proposed Working Group
>
> Assigned Area Director:
>   Wesley Eddy <wes at mti-systems.com>
>
>
> Charter of Working Group:
>
> Description of Working Group
>
> Today's Internet traffic includes interactive real-time media, which is
> often carried via sets of flows using RTP over UDP.  There is no
> generally accepted
> congestion control mechanism for this kind of data flow.  With the
> deployment of
> applications using the RTCWEB protocol suite, the number of such flows
> is likely to
> increase, especially non-fixed-rate flows such as video or adaptive
> audio. There is
> therefore some urgency in specifying one or more congestion control
> mechanisms that
> can find general acceptance.
>
> Congestion control algorithms for interactive real time media may need to
> be quite different from the congestion control of TCP: for example, some
> applications can be more tolerant to loss than delay and jitter. The set of
> requirements for such an algorithm includes, but is not limited to:
>     - Low delay and low jitter for the case where there is no competing
> traffic using other algorithms
>     - Reasonable share of bandwidth when competing with RMCAT traffic,
> other real-time media protocols, and ideally also TCP and other
> protocols. A 'reasonable share' means that no flow has a significantly
> negative
> impact [RFC5033] on other flows and at minimum that no flow starves.
>     - Effective use of signals like packet loss and ECN markings to adapt
> to congestion
>
> The working group will:
>     - Develop a clear understanding of the congestion control
> requirements for RTP flows, and document deficiencies of existing
> mechanisms such as
> TFRC with regards to these requirements.  This must be completed prior to
> finishing any Experimental algorithm specifications.
>     - Identify interactions between applications and RTP flows to enable
> conveying helpful cross-layer information such as per-packet priorities,
> flow
> elasticity, etc. This information might be used to populate an API, but
> the WG will
> not define a specific API itself.
>     - Determine if extensions to RTP/RTCP are needed for carrying
> congestion control feedback, using DCCP as a model.  If so, provide the
> requirements for such extensions to the AVTCORE working group for
> standardization there.
>     - Develop techniques to detect, instrument or diagnose failing to
> meet RT schedules due to failures of components outside of the charter
> scope, possibly in collaboration with IPPM.
>     - Develop a mechanism for identifying shared bottlenecks between
> groups of flows, and means to flexibly allocate their rates within the
> aggregate hitting the shared bottleneck.
>     - Define evaluation criteria for proposed congestion control
> mechanisms, and publish these as an Informational RFC.  This must be
> completed
> prior to finishing any Proposed Standard algorithm specifications.
>     - Find or develop candidate congestion control algorithms, verify
> that these can be tested on the Internet without significant risk, and
> publish one or
> more of these as Experimental RFCs.
>     - Publish evaluation criteria and the result of experimentation with
> these Experimental algorithms on the Internet.  This must be completed
> prior to finishing any Proposed Standard algorithm specifications.
>     - Once an algorithm has been found or developed that meets the
> evaluation criteria, and has a satisfactory amount of documented
> experience on
> the Internet, publish this algorithm as a Standards Track RFC. There
> may be more than one such algorithm.
>     - For each of the Experimental algorithms that have not been selected
> for the Standards Track, the working group will review the algorithm and
> determine whether the RFC should be moved to Historic status via a document
> that briefly describes the issues encountered.  This step is
> particularly important for algorithms with significant flaws, such as
> ones that turn out
> to be harmful to flows using or competing with them.
>
> The work will be guided by the advice laid out in RFC 5405 (UDP Usage
> Guidelines), RFC 2914 (congestion control principles), and RFC5033
> (Specifying New
> Congestion Control Algorithms).
>
> The following topics are out of scope of this working group, on the
> assumption that work on them will proceed elsewhere:
>     - Circuit-breaker algorithms for stopping media flows when network
> conditions render them useless; this work is done in AVTCORE
>     - Media flows for non-interactive purposes like stored video
> playback; those are not as delay sensitive as interactive traffic
>     - Defining active queue management algorithms or modifications to TCP
> of any kind
>     - Multicast congestion control; common control of multiple unicast
> flows is in scope
>     - Topologies other than point-to-point connections; implications on
> multi-hop connections will be considered at a later stage
>
> The working group is expected to work closely with the RAI area,
> including the underlying technologies being worked on in the AVTCORE and
> AVTEXT WGs,
> and the applications/protocol suites being developed in the  CLUE and
> RTCWEB working groups.  It will also coordinate closely with other
> Transport area groups
> working on congestion control, and with the Internet Congestion Control
> Research
> Group of the IRTF.
>
> Deliverables:
>     - Requirements for congestion control algorithms for interactive real
> time media as an Informational RFC
>     - Evaluation criteria for congestion control algorithms for
> interactive real time media as an Informational RFC
>     - RTCP extensions for use with congestion control algorithms as a
> Proposed Standard RFC
>     - Interactions between applications and RTP flows as an Informational
> RFC
>     - Identifying and controlling groups of flows as a Proposed Standard
> RFC
>     - Techniques to detect, instrument or diagnose failing to meet RT
> schedules as either an Informational RFC or on the Standards Track if
> needed for interoperability or other aspects that would justify it.
>     - Candidate congestion control algorithm for interactive real time
> media as Experimental RFCs (likely more than one)
>     - Experimentation and evaluation results for candidate congestion
> control algorithms as an Informational RFC
>     - One or more recommended congestion control algorithms for
> interactive real time media as Proposed Standard RFCs
>
>
>
> Milestones:
>
>
>
>
>
>
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion



-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: mirja.kuehlewind at ikr.uni-stuttgart.de
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------