Re: FW: New Version Notification - draft-mehta-rmt-flute-sdp-04.txt

>>> Layering:
>>> The layering with slash notation was our first consideration for
>>> describing multiple channels some time ago (check out the  discussion on
>>> differentiating channels in the I-D). Using slash notation for one  but
>>> not the other is allowed (again check the I-D for reasons). However,
>>> limiting all FLUTE sessions to only using conecutive numbers  (addresses
>>> for multicast; ports for unicast) is unecessary and potentailly  harmful
>>> as we do not yet a have a comprehensive set fo RMT CC RFCs for each
>>> scheme which has been dicsussed. i.e. we need a means to group  
>>> different
>>> m-lines together: appearing in the same SDP without group:CS for  single
>>> FLUTE session SDPs; have a mid:# belonging to the same group:CS as  
>>> other
>>> media is for multiple FLUTE session SDPs. Use of port numbers to  
>>> differentiate channels (with the same IP
>>> destination/group address) is only useful where some other
>>> application-based congestion control is introduced; indeed it is
>>> recommended only for unicast applications. Differentiation of  channels
>>> based on IP destination/group address is appropriate for multicast
>>> sessions with RMT congestion control. Note, the RMT family uses
>>> layers/channels principally for congestion control. Using them for  FEC
>>> is allowed but if it messes with congestion control deployment on the
>>> public Internet can not be assumed feasible.
>>
>>
>> I think that using CS instead of the layering mechanism is the  right 
>> choice. However I think one should require the usage of CS  for all 
>> cases where a FLUTE session contains more than a single  channel. That 
>> way we are consistent with SDP usage.
> 
> 
> I agree - my main concern with this draft is the implicit grouping of  
> channels ("m=" lines) into a single session, unless otherwise  
> signalled. I strongly prefer a solution where separate "m=" lines  
> denote separate FLUTE sessions, unless the grouping framework is used.
> 

This was also my main point.  The layering suggestion was meant to
encourage thinking about a way that could preserve the m= semantics.

If we don't do layering, this requires explicit grouping and it
may require a mechanism that ensures that receivers that do not
understand grouping do not get confused (but these may be more than
just the 3GPP clients).

Quick question:
If FLUTE uses multiple channels (e.g., for congestion control purposes),
can we always identify a "base" channel -- for the slowest receivers --
(and that would be the single channel if only one was used)?  Could this
be the channel, a receiver listens to if it does not understand the
grouping (unless, maybe, the receiver operates in a specific environment
that implies that all m= lines in a SDP session belong together)?

 From a specification mechanics perspective, I would like to move all
the stuff specific to a certain environment (e.g., MBMS) into an
(informative) appendix but not use normative language for such special
cases.  These considerations are of secondary order and the spec
should express that clearly.

Joerg