[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Rmt] Re: [MMUSIC] FW: New Version Notification - draft-mehta-rmt-flute-sdp-04.txt
Hi,
Please comments and proposals inline.
Rod.Walsh at nokia.com 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: magnus.westerlund at ericsson.com
_______________________________________________
Rmt mailing list
Rmt at ietf.org
https://www1.ietf.org/mailman/listinfo/rmt