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

From: [email-masked]
Date: Wed, 20 Jul 2016 01:02:44 -0700

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 of the IETF.

        Title           : Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions
        Authors         : Colin Perkins
                          Varun Singh
	Filename        : draft-ietf-avtcore-rtp-circuit-breakers-17.txt
	Pages           : 25
	Date            : 2016-07-20

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 these applications, then network congestion can
   lead to uncontrolled packet loss, and a resulting deterioration of
   the user's multimedia experience.  The congestion control algorithm
   acts as a safety measure, stopping RTP flows from using excessive
   resources, and protecting the network from overload.  At the time of
   this writing, however, while there are several proprietary solutions,
   there is no standard algorithm for congestion control of interactive
   RTP flows.

   This document does not propose a congestion control algorithm.  It
   instead defines a minimal set of RTP circuit breakers: conditions
   under which an RTP sender needs to stop transmitting media data, to
   protect the network from excessive congestion.  It is expected that,
   in the absence of long-lived excessive congestion, RTP applications
   running on best-effort IP networks will be able to operate without
   triggering these circuit breakers.  To avoid triggering the RTP
   circuit breaker, any standards-track congestion control algorithms
   defined for RTP will need to operate within the envelope set by these
   RTP circuit breaker algorithms.

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:
https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-circuit-breakers-17

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Colin Perkins <[email-masked]>
Date: Wed, 20 Jul 2016 10:12:21 +0200

This version replaces the discussion of ECN in Section 7 with a statement that there’s no consensus on on how the receipt of ECN feedback will impact the congestion circuit breaker, or indeed whether the congestion circuit breaker ought to take ECN feedback into account. 

Hopefully this is now ready to proceed to publication.

Colin

> On 20 Jul 2016, at 10:02, [email-masked] wrote:
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
https://csperkins.org/

---

From: "Black, David" <[email-masked]>
Date: Wed, 20 Jul 2016 09:45:44 +0000

I agree on content.  One small editorial suggestion ...

   At the time of this writing, there's no consensus on how the receipt
   of ECN feedback will impact the congestion circuit breaker
   (Section 4.3) or indeed whether the congestion circuit breaker ought
   to take ECN feedback into account.  A future version of this memo is
   expected to provide guidance for implementers.

"will impact" -> "is considered by"

Thanks, --David

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Wednesday, July 20, 2016 4:12 AM
> To: IETF AVTCore WG
> Cc: Mirja Kuehlewind (IETF); Black, David; Ben Campbell; Gorry Fairhurst
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-17.txt
> 
> This version replaces the discussion of ECN in Section 7 with a statement that
> there’s no consensus on on how the receipt of ECN feedback will impact the
> congestion circuit breaker, or indeed whether the congestion circuit breaker
> ought to take ECN feedback into account.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Jul 2016 09:42:25 +0200

AVTCORE WG,
(cc RTCWEB and TSVWG)

The AD plans to approve this at the end of the Week. So if you have any 
issues with the new text, this is the time to raise it.

Cheers

Magnus

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Varun Singh <[email-masked]>
Date: Tue, 26 Jul 2016 13:31:43 +0300

Another issue that was brought up during the Berlin IETF meeting, to
clarify the cease transmission for 5-tuple.

I believe section Section 8 provides more concrete guidance on
bundling/grouping media flows and even states that the application should
consider the 6-tuple (+DSCP) when deciding to cease transmission.

In section 4.5, I would propose reshuffling the statements a bit to make
the guidance more appropriate:

OLD:
   What it means to cease transmission depends on the application. The
   intention is that the application will stop sending RTP data packets
   on a particular 5-tuple (transport protocol, source and destination
   ports, source and destination IP addresses), until whatever network
   problem that triggered the RTP circuit breaker has dissipated.  This
   could mean stopping a single RTP flow, or it could mean that multiple
   bundled RTP flows are stopped.

NEW:

   What it means to cease transmission depends on the application. This
   could mean stopping a single RTP flow, or it could mean that multiple
   bundled RTP flows are stopped. The intention is that the application
will
   stop sending RTP data packets on a particular 5-tuple (transport
protocol,
   source and destination ports, source and destination IP addresses),
until
   whatever network problem that triggered the RTP circuit breaker has
   dissipated.

Regards,
Varun.

-- 
http://www.callstats.io