[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 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:jo at netlab.hut.fi]
>Sent: 24 November, 2005 23:11
>To: Magnus Westerlund
>Cc: Walsh Rod (Nokia-NRC/Tampere); mmusic at ietf.org; rmt at ietf.org
>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?
>>>
>>
>>
>
>
_______________________________________________
Rmt mailing list
Rmt at ietf.org
https://www1.ietf.org/mailman/listinfo/rmt