Subject: [AVT] WGLC on draft-ietf-avt-rtcp-guidelines-02

From: Roni Even <[email-masked]>
Date: Sun, 10 Jan 2010 10:33:36 +0200

Hi,

I would like to start a working group last call on Guidelines for Extending
the RTP Control Protocol (RTCP) in

http://tools.ietf.org/html/draft-ietf-avt-rtcp-guidelines-02 

The WGLC will end on January 27th , Please review the draft and send
comments to the list

Roni Even

AVT co-chair

---

From: "Christian Hoene" <[email-masked]>
Date: Tue, 12 Jan 2010 15:40:45 +0100

Hello,

I just read the draft to understand how to support rate and congestion
control for a future IETF codec. The envisioned codec is intended for
interactive audio and thus is used bidirectional (always).

Based on the draft and RFC 4585, I understand that RTCP shall not be used
for a fast feedback loop. But how to implement a proper feedback loop?

1)      Shall we use RTP on top of a transport protocol like TCP and DCCP
that already include a feedback. But then again, how to support codec and
playout specific feedback that is related to the current perceptual quality
and acoustic round trip delay?

2)      Should SIP or H.323 a renegotiation message be used? That might be
too slow, too.

3)      Could a RTP header extension, the Marker bit or the payload format
be used to signal congestion?

4)      Or shall the codec include a control feedback loop because it works
bidirectional anyhow?

In the case of 2 and 3, RTP must be used bidirectional without multicast
distribution, mixers and translators. But  this is against its design
philosophy because RTP is not originally intended to work bidirectional
(only RTCP is). Thus, maybe using RTCP remains a solution for a fast
feedback loop? Or do we need an extension to RTP that defines how it works
bidirectional? Or did I miss any of the recent extensions to RTP that might
be suitable? The draft does not give an answer to those question. 

Beside that the draft looks fine to me.

Christian

---------------------------------------------------------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of Tübingen 

Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 
 <http://www.net.uni-tuebingen.de/> http://www.net.uni-tuebingen.de/

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Roni
Even
Gesendet: Sonntag, 10. Januar 2010 09:34
An: [email-masked]
Cc: [email-masked]
Betreff: [AVT] WGLC on draft-ietf-avt-rtcp-guidelines-02

Hi,

Roni Even

AVT co-chair

---

From: Roni Even <[email-masked]>
Date: Tue, 12 Jan 2010 17:26:40 +0200

Christian,

I suggest you look at
http://tools.ietf.org/html/draft-ietf-avt-rapid-rtp-sync-09 that updates
regarding RTCP timing in order to see if the RTCP feedback is fast enough.

Congestion is discussed in
http://tools.ietf.org/id/draft-westerlund-avt-ecn-for-rtp-02.txt 

The codec cannot assume that it works bidirectional, since it can be used
for streaming applications. 

BTW: H.263 annex N was talking about a feedback channel but as far as I know
this was not implemented. The codec flow control is discussed in RFC 5104.

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian Hoene
Sent: Tuesday, January 12, 2010 4:41 PM
To: 'Colin Perkins'; 'Joerg Ott'
Cc: [email-masked]; [email-masked]; 'Patrick Schreiner'
Subject: Re: [AVT] WGLC on draft-ietf-avt-rtcp-guidelines-02

Hello,

Christian

Dr.-Ing. Christian Hoene

Hi,

Roni Even

AVT co-chair

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Jan 2010 19:57:15 +0000

Christian,

RTCP provides relatively low-rate feedback suitable for rate  
adaptation, to avoid persistent congestion, and to provide codec  
control functions. RTCP can't, in general, provide a fast (per-RTT)  
feedback loop. If you need such rapid adaptation, you should run RTP  
over a congestion controlled transport protocol, such as TCP or DCCP,  
and adjust the sending rate based on the transport layer feedback.

Colin

On 12 Jan 2010, at 14:40, Christian Hoene wrote:
> Hello,
>
> I just read the draft to understand how to support rate and  
> congestion control for a future IETF codec. The envisioned codec is  
> intended for interactive audio and thus is used bidirectional  
> (always).
>
> Based on the draft and RFC 4585, I understand that RTCP shall not be  
> used for a fast feedback loop. But how to implement a proper  
> feedback loop?
> 1)      Shall we use RTP on top of a transport protocol like TCP and  
> DCCP that already include a feedback. But then again, how to support  
> codec and playout specific feedback that is related to the current  
> perceptual quality and acoustic round trip delay?
> 2)      Should SIP or H.323 a renegotiation message be used? That  
> might be too slow, too.
> 3)      Could a RTP header extension, the Marker bit or the payload  
> format be used to signal congestion?
> 4)      Or shall the codec include a control feedback loop because  
> it works bidirectional anyhow?
>
> In the case of 2 and 3, RTP must be used bidirectional without  
> multicast distribution, mixers and translators. But  this is against  
> its design philosophy because RTP is not originally intended to work  
> bidirectional (only RTCP is). Thus, maybe using RTCP remains a  
> solution for a fast feedback loop? Or do we need an extension to RTP  
> that defines how it works bidirectional? Or did I miss any of the  
> recent extensions to RTP that might be suitable? The draft does not  
> give an answer to those question.
>
> http://www.net.uni-tuebingen.de/
>
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag  
> von Roni Even
> I would like to start a working group last call on Guidelines for  
> Extending the RTP Control Protocol (RTCP) in
>

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 24 Jan 2010 13:41:25 -0800

I read the draft. No major comments. All reads well except a few minor
points:

- Section 3, second parag. The reference to RTCPSSM is missing.
- Page 7, just below Figure 1. Rather than "slower timescales", "longer
timescales" sounds better to me.
- Page 12, first parag. "an old-style mechanisms" --> "mechanism"
- Various places. Use a hyphen for things like,
transport/applications-layer messages instead of transport/application
layer messages.

-acbegen