Re: [codec] #17: Feedback and control loop?

["codec issue tracker" <[e-mail]>]

#17: Feedback and control loop?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  minor                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  Active WG Document      |    Keywords:     
------------------------------------+---------------------------------------

Comment(by hoene@…):

 [Christian]:
 Requirement: Reliable on the Internet

    The ACS must be optimized towards acoustic real-time communications
    over the Internet, and must have the flexibility to adjust to the
    environment it operates in. Based on the quality of the end-to-end
    speech packet transmission, the codec should adapt its quality and
    delay to achieve an optimal benefit for the user.

    As most Internet transport, it should be used with a wide range of
    condition allowing a high reliability regardless the networking
    condition. The reliability of the audio transmission should be high,
    even in cases of low and varying bandwidth. This implies that the
    codec is used on top of a transport protocol that implements a
    congestion control algorithm and that the ACS adapts to changes of
    available bandwidth. For example, if the available transmission
    bandwidth is too low to allow the codec to transmit audio at a high
    quality, the application can lower the sampling, bit or frame rate of
    the stream at the cost of higher algorithmic delay or a degraded
    audio quality.

 Reiability and congestion control :

    The acoustic transmission should be reliable and robust. The ACS
    shall be not only robust against packet losses but also for periods
    of low bandwidth.

    The mean availability of the audio transmissions, calculated over all
    users, might be one of the metrics for assessing the performance of
    an Internet audio codec.

    The ACS should adapt to the current network situation. Also, the
    codecs of ACS themselves must be adaptable, because switching among
    multiple codecs is difficult to negotiate and unlikely to work well
    in situations of inter-operation.

    Responding to congestion is a more complex issue and out of the scope
    of this document. However, it shall be defined on how to use existing
    congestion control protocols like DCCP and TCP. The ACS shall provide
    the mechanisms that congestion control requires from the codec (i.e.
    bitrate/framerate adaptability).

    Because of the interactive nature of the acoustic transmission, the
    bidirectional transmission of audio content can be used for
    transmitting the required feedback and implementing a control loop.

 Side channel

    Congestion control should be must for all Internet applications also
    for the ACS. [RFC3550] suggests in Chapter 10 somewhere that the RTP
    profile should care for rate adaptation. Thus, the ACS should take
    advantage of a feedback loop for variable coding parameter control in
    order to allow a wide range of operation and to adapt to the the
    current available bandwidth and processing power.

    Congestion control per se is outside the review of this group, but
    providing the hooks for a congestion-control mechanism to interact
    with the codec is quite important. For example, running this codec on
    a TFRC-enabled or DCCP RTP stream - TFRC and DCCP need to be able to
    adjust (via the application) the bitrate of the codec in order to
    implement congestion control and perhaps adjust packetization
    periods/packet-rates.

    A side channel for adaptation can be added. This would make sense
    because in usage scenarios audio is always transmitted in both
    directions. Adding a control channel would give a real advantage to
    existing codec designs. Alternatively, such as side channel can be
    also added with alternative solutions, such as handling that
    communication in SIP/SDP and in RTP/RTCP.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/17#comment:2>
codec <http://tools.ietf.org/codec/>