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

Hi Magnus,

if I am getting this right, nothing in our mail contradicts the
m=/c= line approach for layered coding I mentioned below.  This
would also address your uneasiness about the media attributes
inherited from the first m= line since there will only be one.

Cheers,
Joerg

> Hi,
> 
> Some input on the SDP flute mechanism and especially in relation to the 
> FEC grouping semantics:
> 
> 1. The "CS" definition is not generic and talks explicitly about FLUTE 
> as part of the definition. This should probably be changed to allow 
> other usage.
> 
> 2. To my understanding FLUTE couldn't use the FEC semantics while ULP 
> potentially could use CS if defined more generic. The reason is that 
> FLUTE is not strictly grouping things for the purpose of FEC. It is 
> having a definition of multiple channels to allow for congestion 
> control, fault tolerant routing, etc. That data is protected using FEC 
> is not required but will be common and all channels are FLUTE internally 
> identified correctly. If ULP used CS rather than FEC it would loose the 
> indication on that level that there are source data sessions and then 
> FEC repair data sessions. However this will be evident if one 
> investigates the individual media level information.
> 
> 3. I still don't like this primary definition stuff where secondary 
> media lines inherit all attributes from the primary one. But I think I 
> can live with it. However it does have the potential to confuse a lot of 
> people if CS is used in other contexts than FLUTE. As I understand it to 
> be a property of CS grouping rather than anything else.
> 
> 4. Section 3.9: I am considering if FLUTE couldn't benefit from using 
> the TIAS bandwidth modifier (RFC 3890). However it might not be really 
> considered that that for example a mid point translator would change the 
> IP version and would need to provide a useful bandwidth measurement or? 
> If TIAS is to be allowed then I would suggest that you define which 
> headers that are not included in the bandwidth calculation (IP/UDP) or 
> also some of the RMT related headers that always have a fixed size?
> 
> 
> 
> Editorial issues:
> 
> E1. Section 3.1:
> "The
>    FLUTE/UDP protocol identifier specifies that the session being
>    described will use the FLUTE [1] protocol on top of a UDP connection."
> 
> The last word "connection" is very misplaced for UDP. I would suggest to 
> replace it with "flow". Isn't is also "an" UDP flow.
> 
> E2. Section 3.2, page 7, second last paragraph:
> "Just as session-level attributes are inherited to media-level
>    declarations (unless specifically overwritten by an additional media-
>    level attribute), Primary Media attributes SHALL be inherited to all
>    media of a particular Composite Session group and these MAY be
>    overwritten these where an attribute syntax allows."
> 
> The last "these" should be deleted?
> 
> Cheers
> 
> Magnus
> 
> Joerg Ott wrote:
> 
>> Hi Rod,
>>
>> since you asked for feedback :-)
>>
>> I haven't checked for nits but, overall, the attributes and
>> the outline looks ok.
>>
>> You know that I am quite unhappy with the general default rule.
>> In essence, we are using the grouping framework to indicate non-
>> grouping.  If I have want to specify two independent FLUTE sessions
>> each on one m= line, I have to include the grouping attribute and
>> specify that no grouping exists.  Which is not exactly intuitive :-)
>>
>> Since traditional SDP applications haven't used FLUTE, there is
>> probably not so much of a backwards compatibility problem.
>>
>> Nevertheless, this breaks with the SDP semantics we have been using
>> so far, namely that each m= line indicates a new media session
>> unless explicitly specified otherwise.
>>
>> I feel architecturally uneasy with introducing behavior that makes
>> the interpretation of media sessions dependent on the session type.
>>
>> Here's another proposal:
>>
>> I have also taken another look at sdp-25: the good ol' multicast
>> support described there in section 5.7 allows you to specify
>> multiple layers.  And from the your draft, most attributes apply
>> to the media session as a whole, except for the fec identification.
>> This identification could just be done by order or appearance.
>> If you do not need to rely on other than consecutive port numbers
>> for the different layers, this c= semantics peered with the m=
>> port range might even do for you.  As there is no negotiation and
>> the sender can choose the ports (do you multicast through NATs?)
>> that restriction should be ok.
>>
>> On a side note:
>> How does this relate to draft-ietf-mmusic-fec-grouping-00.txt?
>> And do we need both of these?
>>
> 
>