Re: [codec] #16: Multicast?

[Colin Perkins <[e-mail]>]

On 21 Apr 2010, at 12:14, Christian Hoene wrote:
>> On 21 Apr 2010, at 10:42, codec issue tracker wrote:
>>> #16: Multicast?
>>> ------------------------------------
>>> +----------------------------------
>>> Reporter:  hoene@.                 |       Owner:
>>>   Type:  enhancement             |      Status:  new
>>> Priority:  trivial                 |   Milestone:
>>> Component:  requirements            |     Version:
>>> Severity:  Active WG Document      |    Keywords:
>>> ------------------------------------
>>> +----------------------------------
>>> The question arrose whether the interactive CODEC MUST support
>>> multicast in addition to teleconferencing.
>>>
>>> On 04/13/2010 11:35 AM, Christian Hoene wrote:
>>>>>> P.S. On the same note, does anybody here cares about using this
>>>>>> CODEC with multicast? Is there a single commercial multicast
>>>>>> voice deployment? From what I've seen all multicast does is
>>>>>> making IETF voice standards harder to understand or implement.
>>>>>
>>>>> I think that would be a mistake to ignore multicast - not because
>>>>> of multicast itself, but because of Xcast (RFC 5058) which is a
>>>>> promising technology to replace centralized conference bridges.
>>>>
>>>> Regarding multicast:
>>>>
>>>> I think we shall start at user requirements and scenarios.
>>>> Teleconference (including mono or spatial audio) might be good
>>>> starting point. Virtual environments like second live would require
>>>> multicast communication, too. If the requirements of these
>>>> scenarios are well understand, we can start to talk about potential
>>>> solutions like IP multicast, Xcast or conference bridges.
>>
>>
>> RTP is inherently a group communication protocol, and any codec  
>> designed for use with RTP should consider operation in various  
>> different types of group communication scenario (not just  
>> multicast). RFC 5117 is a good place to start when considering the  
>> different types of topology in which RTP is used, and the possible  
>> placement of mixing and switching functions which the codec will  
>> need to work with.
>
> I have to admit that my thinking is complete different. I first  
> start with user requirements, then look how to achieve them, and  
> finally consider on how to map them on existing standards - not the  
> other way around.
>
> Users do demand for teleconferencing, preferable at high quality  
> (good spatial audio quality, low acoustic latency and reliable).  
> Thus, this is a MUST requirement.
>
> I believe that multicast support NEEDS NOT to be particular  
> optimized due to the following two reasons:

You'll notice that I said that RTP is a group communication protocol,  
not explicitly a multicast protocol. Multicast groups are one of many  
ways in which RTP is used for group communication, but not the only one.

> a) RFC5117: 4.1.3.  Per Domain Bit-Rate Adaptation
>
>   Participants are most likely to be connected to each other with a
>   heterogeneous set of paths.  This makes congestion control in a  
> Point
>   to Multipoint set problematic.  For the ASM and "relay" scenario,
>   each individual sender has to adapt to the receiver with the least
>   capable path.  This is no longer necessary when Media Translators,
>   Mixers, or MCUs are involved, as each participant only needs to  
> adapt
>   to the slowest path within its own domain.  The Translator, Mixer,  
> or
>   MCU topologies all require their respective outgoing streams to
>   adjust the bit-rate, packet-rate, etc., to adapt to the least  
> capable
>   path in each of the other domains.  That way one can avoid lowering
>   the quality to the least-capable participant in all the domains at
>   the cost (complexity, delay, equipment) of the Mixer or Translator.
>
> Indeed, the CODEC SHOULD be adapted on each path to achieve best  
> quality.
>
> b) Multicast is used (to my best knowledge) mainly locally and not  
> throughout the Internet, thus if we want to support global  
> interactive communication with a good CODEC support of MULTICAST  
> cannot be considered as granted.

No-one said it should be taken for granted. A multicast group is one  
of the different group communication scenarios where the codec can be  
used. That there is a multicast group transport is, I would expect,  
largely irrelevant to the codec design. That such a group results in  
potentially many audio streams that must be mixed by the end systems,  
rather than by middleboxes, is probably more relevant.

The other topologies discussed in RFC 5117 may require different a  
trade-off. This group should probably review them, to consider how  
(if) they affect the codec design.

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