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

From: [email-masked]
Date: Fri, 11 Nov 2005 13:58:54 +0200

FYI, the FLUTE-SDP I-D update is now available.

This was identified by 3GPP as a dependency for release 6. Hence, if you
do identify problems please state ASAP.

Also, this will be handled in RMT style, i.e. is for experimental. When
FLUTE (and it's dependencies) go standards track, this FLUTE-SDP will be
updated for that too. However, we expect the experimental FLUTE-SDP to
be already ready for standards track except for trivial nits (if any).

Cheers, Rod.

PS Anyone not interested in FLUTE, but generally interested in SDP and
MMUSIC should still take a look at the CS token for SDP grouping - a
handy device for setting session semantics independently of "all an SDP
instance" and "per media" (which is defined as it is needed to declare
multiple FLUTE session (with multiple FLUTE channels) per SDP).

PPS There are many people who have help. If we forgot your name on the
acknowledgements please flame me directly and I'll sort it out.

>-----Original Message-----
>From: Michael Lee [mailto:[email-masked]] On Behalf Of 
>ext ID Tracker
>Sent: 10 November, 2005 22:50
>To: Mehta Harsh (Nokia-NET/Helsinki); [email-masked]; 
>Walsh Rod (Nokia-NRC/Tampere); [email-masked]; 
>[email-masked]
>Subject: New Version Notification - draft-mehta-rmt-flute-sdp-04.txt 
>
>New version (-04) has been submitted for 
>draft-mehta-rmt-flute-sdp-04.txt.
>http://www.ietf.org/internet-drafts/draft-mehta-rmt-flute-sdp-04.txt
>
>Sub state has been changed to AD Follow up from New Id Needed
>
>IETF Secretariat.
>
>

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Joerg Ott <[email-masked]>
Date: Thu, 24 Nov 2005 17:19:54 +0200

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?

Cheers,
Joerg

PS: Is there any chance to fix this stuff in 3GPP?

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 24 Nov 2005 17:28:01 +0100

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

-- 

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-masked]

---

From: Joerg Ott <[email-masked]>
Date: Thu, 24 Nov 2005 23:11:12 +0200

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 25 Nov 2005 11:38:37 +0100

> inherited from the first m= line since there will only be one.

I don't think that using the / approach to layering is the right one. 
More and more SDP attributes apply to a single session and not a layered 
one. Consider for example the key management for SRTP. These applies to 
a single stream and does not work for multiple streams.

Thus I think using a structure with a grouping attribute is the way 
forward. Or actually the right way would be to abandon SDP totally and 
get a description format that actually can describe things properly with 
complex relations. But I guess we will continue to hack SDP for this.

But I do support your statement that we shouldn't change the default 
meaning of media line being a individual stream. And I don't see an 
issue of changing this for the FLUTE SDP draft. But more about this in a 
response to Rod's email.

Cheers

Magnus Westerlund