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

Hi,

Please comments and proposals inline.

[email protected] wrote:
> 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.
> 

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.

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

Yes!

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

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.

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

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?


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

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