Subject: [rmcat] I-D Action: draft-ietf-rmcat-cc-codec-interactions-01.txt

From: [email-masked]
Date: Sun, 18 Oct 2015 08:30:29 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the RTP Media Congestion Avoidance Techniques Working Group of the IETF.

        Title           : Congestion Control and Codec interactions in RTP Applications
        Authors         : Mo Zanaty
                          Varun Singh
                          Suhas Nandakumar
                          Ericsson AB
	Filename        : draft-ietf-rmcat-cc-codec-interactions-01.txt
	Pages           : 12
	Date            : 2015-10-18

Abstract:
   Interactive real-time media applications that use the Real-time
   Transport Protocol (RTP) over the User Datagram Protocol (UDP) must
   use congestion control techniques above the UDP layer since it
   provides none.  This memo describes the interactions and conceptual
   interfaces necessary between the application components that relate
   to congestion control, specifically the media codec control layer,
   and the components dedicated to congestion control functions.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-codec-interactions/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rmcat-cc-codec-interactions-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-cc-codec-interactions-01

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: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Fri, 30 Oct 2015 20:41:51 +0100

Hi,

Please accept the following comments to the new document.
Use as you see fit.

General Comments:

* The document describes both a conceptual model for the various
interactions as well as the
particular details of the codec-cc interactions. Perhaps this is as it
should be, but I am still not really sure about
that this conceptual model belongs in this document. Anyway it is necessary
to have it somewhere.

* The document in details refer to interaction with FEC, but FEC is not put
in place in the conceptual model.
I think the conceptual model, if it should be here, should make reference to
where FEC functions logical reside (in codec or outside of codec..).

Detailed comments:

* Section 5: First paragraph should be revised. This section includes
optional as well as mandatory (necessary) requirements.

* Section 5.1:

Not sure what the following statement is intended to say - This sounds like
requirements for the CC or requirements for the codecs to apply on top of
the rate provided from the CC ?

"The rate must never exceed permanent limits established in
   session signaling such as the SDP bandwidth attribute [RFC4566] nor
   temporary limits in RTCP such as TMMBR [RFC5104] or REMB
   [I-D.alvestrand-rmcat-remb]. "

*Section 5.2.3:

"Note this is unrecoverable post-repair loss after
   retransmission or forward error correction."

Is it assumed that the CC would have this intelligence to distinguish
post-repair loss from loss ?

* Section 5.2.4

Is it considered likely that the CC could do anything to differentiate on
random versus periodic versus consecutive losses ?

Is section 5.2.5 not special FEC consideration of 5.2.4 ?

* Section 5.2.6:  So this interaction is CC <-- --> FEC - or ?

Some comments given to  draft-zanaty-rmcat-cc-codec-interactions-00, email
of July 19'th, also apply to this draft.

BR, Karen

> -----Original Message-----
> From: rmcat [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: 18. oktober 2015 17:30
> To: [email-masked]
> Cc: [email-masked]
> Subject: [rmcat] I-D Action: draft-ietf-rmcat-cc-codec-interactions-01.txt
>
>
>  This draft is a work item of the RTP Media Congestion Avoidance
> Techniques
> Working Group of the IETF.
>