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

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?
> 


-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email protected]