Re: [codec] #16: Multicast?

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

#16: Multicast?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |        Owner:        
     Type:  enhancement             |       Status:  closed
 Priority:  trivial                 |    Milestone:        
Component:  requirements            |      Version:        
 Severity:  Active WG Document      |   Resolution:  fixed 
 Keywords:                          |  
------------------------------------+---------------------------------------
Changes (by hoene@…):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 [Colin]:
 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.

 [Christian]:

 I believe that multicast support NEEDS NOT to be particular optimized due
 to the following two reasons:

 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.

 [Marshall]:
 It is not clear to me what supporting multicast would entail here. If this
 is a codec over RTP, then what is to stop it from being multicast ?

 [Stephan]:
 Teleconferencing standards (both in the ITU-T and the IETF) support
 multicast..  It would be awkward if the codec decision was somehow coupled
 to the transport, and (IMHO) architecturally wrong.
 While it is probably true that multicast is more likely to be used on
 enterprise networks, I don't see that as terribly relevant.
 I see no technical reason to NEED NOT multicast.

 [Colin]:
 Nothing. However group conferences implemented using multicast require
 end system mixing of potentially large numbers of active audio
 streams, whereas those implemented using conference bridges do the
 mixing in a single central location, and generally suppress all but
 one speaker. The differences in mixing and the number of simultaneous
 active streams that might be received potentially affect the design of
 the codec.

 [Marshall]:
 At any rate, I would regard multicast support as a SHOULD.

 [Christian]:
 The scalable [teleconference] scenario is [...]:
 -       Central processing and mixing for many participants .
 -       N to 1 and 1 to N communication using efficient distribution
 mechanisms (RTP group communication and IP multicast).

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