RE: [MMUSIC] FW: New Version Notification - draft-mehta-rmt-flute-sdp-04.txt

Brief status check:

Taking into account the thread's earlier comments, questions and
answers, the only unresolved issue with draft-mehta-rmt-flute-sdp-04 is
the default mode of multiple FLUTE media resolve to a single FLUTE
session where CS is not used. Joerg, Colin and Magnus have expressed
reservations about this and a (strong) preference that either the
default (without CS) is that multiple FLUTE media resolve to different
FLUTE sessions and that description of a multi-channel FLUTE session
would mandate use of CS in all cases.

I have expressed my opinions and technical understanding easily enough
so see the thread if you want a technical counter-argument.

To make progress (and get my well deserved Christmas vacation), I would
be delighted to concede the point and move on. To my knowledge, there is
only one obstacle to this. Not 3GPP (who only allow one FLUTE media per
SDP and no other media); but DVB. DVB adopted 3GPP's SDP and allowed
multi-channel FLUTE sessions by the mechanism described as "the default
mode". This is not backwards compatible with the "mandated CS" proposal.
To complicate matters only a little, OMA will consider the use of SDP
too and since IP over DVB-H is already under commercial trial (i.e.
easily the furthest ahead mass role out of FLUTE), not adopting an
approach harmonious with DVB would be irrational. 

So, please help me in constructing an easy to understand explanation of
why "the default mode" brakes SDP semantics so we have a tangible hope
of presenting this as a change request to DVB (and OMA). 

So, please, please, please help!

Cheers, Rod.

PS DVB SDP should be made public at
http://www.dvb-h-online.org/technology.htm under CDP spec (A101) anyway
now, though it's been frozen a while.

PPS Since there seems to be only one issue with the I-D, I'm no longer
toying with the idea of splitting into two I-Ds 3GPP-aligned minimal SDP
and a full multi-channel multi-session enhanced SDP. (Of course this is
an option if it adds yet another month to the process)



>-----Original Message-----
>From: ext Joerg Ott [mailto:[email protected]] 
>Sent: 27 November, 2005 00:02
>To: Colin Perkins
>Cc: Magnus Westerlund; Walsh Rod (Nokia-NRC/Tampere); 
>[email protected]; [email protected]
>Subject: Re: [MMUSIC] 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
>
>
>