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

From: [email-masked]
Date: Fri, 25 Nov 2005 11:28:23 +0200

Hi Jeorg et al.

---

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.

---

Generic CS:

1st quote:

3.2.  Composite Session Semantics

   The Composite Session mechanism enables the grouping of FLUTE/UDP
   media lines in to distinct FLUTE sessions.

Maybe we should delete "FLUTE/UDP" and "FLUTE" and put a paragraph break
after this so that the notion of generic comes first and then the
specifics for FLUTE?

2nd quote:

   The Composite Session mechanism is specified to solve the problem of
   describing multiple FLUTE sessions in a single SDP instance.
   However, this does not place any restrictions on the use of the
   Composite Session mechanism with transport protocols other than
   FLUTE/UDP, nor on whether a complete SDP would include media of other
   transport protocols too.  Specification of semantics beyond the use
   of FLUTE sessions is outside the scope of this document.

Is this enough, or would a different approach be needed (e.g. 3.2
<Generic> Composition Session Semantics; 3.2.1 FLUTE Composite
Sessions)?

---

TIAS:

Magnus, please hurry on those considerations! (They could be introduced
in the ESP->PS phase, but if they are useful they ought to already be in
now. BTW, though no FLUTE-ROHC profile currently exists, would such a
change effect the TIAS? I guess not that the FLUTE client would get the
stream 'post-header-restoration').

Also, thanks for the 2 nits - will do.

---

fec-grouping-00:

FEC declatations are different. FLUTE could not use fec-grouping-00's
but I think the reverse is possible; ULP could use
draft-mehta-rmt-flute-sdp-04's - unless there is some specific need to
apply rtpmap to this.

OTOH, the FEC token sematics seem to be a subset of CS. So unless there
would be some use of specifying multiple FEC grouping per CS or
overlapping FEC and CS groups, maybe they could both use CS. Is there
such a use? (My ULP-uneducated guess would be 'no' so the FEC token
would become redundant).

A higher level consideration is whether fec-grouping-00 and ULP work
needs aligning with the new FECFRAME WG? By definition flute-sdp has
been equally exposed in RMT and MMUSIC, but I suspect ULP is not so well
known in RMT.

---

Cheers, Rod.

>-----Original Message-----
>From: ext Joerg Ott [mailto:[email-masked]] 
>Sent: 24 November, 2005 23:11
>To: Magnus Westerlund
>Cc: Walsh Rod (Nokia-NRC/Tampere); [email-masked]; [email-masked]
>Subject: Re: [MMUSIC] 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?
>>>
>> 
>> 
>
>

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 25 Nov 2005 13:49:36 +0100

Hi,

Please comments and proposals inline.

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

> after this so that the notion of generic comes first and then the

Yes!

> <Generic> Composition Session Semantics; 3.2.1 FLUTE Composite

I think splitting it into separate sections are good. As other may 
reference the generic semantics's section explicitly. Avoiding having 
FLUTE mixed into this avoids confusion.

> stream 'post-header-restoration').

It was primarily a question to the people that is going to use this! 
TIAS was developed to make it possible to recalculate the session 
bit-rate when traffic is moved from one domain to another and thus 
changes the overhead. I think TIAS makes sense as it allows a receiver 
to take both header compression or the occurrences of translators into 
consideration when determining what bit-rate that will be need at the 
local part. Thus I propose that TIAS is include.

The second issue around TIAS is which headers should be include in the 
TIAS value and which should be excluded and added by the receiver 
calculating the total bit-rate. To me it seems obvious that we can 
exclude IP/UDP header from the TIAS value. The one where I am not 
certain is if the default LCT header can also be excluded in a 
consistent way. The requirement is that header size does not vary during 
the session and has a well determined size, at least based on the 
session signalling. So any comments on the suitability of the LCT header 
for such inclusion?

> been equally exposed in RMT and MMUSIC, but I suspect ULP is not so well

I think it makes sense to have both CS and FEC. Where CS would be used 
to group all streams that are part of the same combined media session, 
like layering. FEC is used to bind together the streams that are 
directly related for FEC usage. An example where this could be combined 
would be multiple multicast layer where each layer is individually 
protected using FEC, or even more "fun" where each layer contains FEC 
for its own and all lower layers.

Example:

a=group:CS 1 2 3 4 5 6
a=group:FEC 1 2
a=group:FEC 3 4
a=group:FEC 5 6
m=video 5000 RTP/AVP 97
c=224.1.2.3
a=rtpmap: SVC/90000
a=fid:1
m=video 5002 RTP/AVP 98
c=224.1.2.3
a=rtpmap: ulp/90000
a=fid:2
m=video 5000 RTP/AVP 97
c=224.1.2.4
a=rtpmap: SVC/90000
a=fid:3
m=video 5002 RTP/AVP 98
c=224.1.2.4
a=rtpmap: ulp/90000
a=fid:4
m=video 5000 RTP/AVP 97
c=224.1.2.5
a=rtpmap: SVC/90000
a=fid:5
m=video 5002 RTP/AVP 98
c=224.1.2.5
a=rtpmap: ulp/90000
a=fid:6

Cheers

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: Colin Perkins <[email-masked]>
Date: Sat, 26 Nov 2005 12:53:34 +0000

Hi,

On 25 Nov 2005, at 12:49, Magnus Westerlund wrote:
...
>> media is for multiple FLUTE session SDPs. Use of port numbers to  
>> differentiate channels (with the same IP
> 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.

Colin

---

From: Joerg Ott <[email-masked]>
Date: Sun, 27 Nov 2005 00:02:02 +0200

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

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