Subject: [AVT] Minutes from IETF 62 (Minneapolis)

From: Colin Perkins <[email-masked]>
Date: Mon, 4 Apr 2005 16:51:27 +0100

Folks,

Attached are minutes from the AVT working group in Minneapolis. Please 
send any comments or corrections to the chairs by 7th April.

Colin
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: 04 Apr 2005 16:47:07 -0400

>TFRC VoIP mode
>   draft-ietf-dccp-tfrc-voip-01.txt

>   Henning Schulzrinne commented that much of the effort in desiging this
>   new algorithm has been put into operation at high loss rates, a region
>   where VoIP flows typically don't operate. He asked if it might be more
>   appropriate to simply cease transmission when the loss rate increases,
>   rather than spend the effort to more the protocol operate in a regime 
>   where the applications generally don't work.

        What loss rates are you talking about?  It depends a lot on the
various technologies you use, but good conversations can occur at 10, even
20% loss, and understandable conversations at 30 and even 50% loss.  Those
loss rates will pretty much submarine most other (TCP) IP applications (try
browsing at 10 or 20% loss).  And the cases I give don't use any sort of
FEC/etc; using those and other mechanisms should extend it even further.

        Obviously tfrc-voip is targetted at protocols that use some
form of variable-bitrate codec or can switch/renegotiate codecs to adapt.
Most "classic" narrowband voice protocols would not be targets for this.
Some of the newer wideband codecs are adaptable (though this might require
negotiating multiple payload types in some cases), and obviously other
types of media might be targets (though those other types might not fit
the definition of "small" for packetsizes).

>   Magnus Westerlund agreed with Sally, commenting that there may be
>   applications that can scale their transmission rate and make use of the
>   limited capacity available with high loss rates.

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Tue, 5 Apr 2005 10:13:20 +0100

> FEC/etc; using those and other mechanisms should extend it even 

It's certainly possible to make VoIP applications work at those loss 
rates, depending on the codec and the amount of error concealment you 
implement, but the media quality will be poor. Few would argue that 
it's a desirable operating regime for either the application or the 
network.

It's not clear that making the congestion control work well for those 
loss rates is a productive use of time (although it certainly doesn't 
cause any problems if it does work).

> Most "classic" narrowband voice protocols would not be targets for 

Yes, although I would hope it's possible to run traditional narrowband 
VoIP on a congestion controlled connection, provided the rate 
determined by the congestion control algorithm is not less than that 
needed by the codec.

> the definition of "small" for packetsizes).

Certainly.

Colin

---

From: Harinath Garudadri <[email-masked]>
Date: Tue, 05 Apr 2005 11:52:10 -0700

At 02:13 AM 4/5/2005, Colin Perkins wrote:
>implement, but the media quality will be poor.

I am not sure if one can categorically say "quality WILL be poor", as it 
depends on the codec and the error concealment.

>Few would argue that it's a desirable operating regime for either the 
>application or the network.

While not typical/preferable operating points, we need to consider such 
cases as they do occur in practice, such as deep fades and handoffs in 
wireless networks. Thanks, hari.

>It's not clear that making the congestion control work well for those loss 
>rates is a productive use of time (although it certainly doesn't cause any 
>problems if it does work).
>
>VoIP on a congestion controlled connection, provided the rate determined 
>by the congestion control algorithm is not less than that needed by the codec.
>

Dr. Hari Garudadri
Qualcomm Inc.
work    : +1 858 651 6383
mobile : +1 858 229 2801