Subject: [AVT] Comments on draft-ietf-avt-rapid-acquisition-for-rtp-08

From: Colin Perkins <[email-masked]>
Date: Sun, 11 Apr 2010 20:51:16 +0100

I've reviewed draft-ietf-avt-rapid-acquisition-for-rtp-08.txt, and  
have some comments. Mainly, the draft is unclear whether the unicast  
RAMS and retransmission traffic shares the same SSRC space as the  
multicast media stream, and hence is part of the same RTP session, or  
if it's a separate RTP session with its own SSRC space. Either  
approach can be made to work, I believe, but it affects the design and  
implementation choices, and the lack of clarity throughout the draft  
is likely to cause interoperability problems.

Section 1.1 in particular is extremely confusing:

- I don't believe it's correct to say that "All RTP streams within a  
single RTP session are sent towards the same transport address, i.e.,  
they share the same destination IP address and port". The text in  
Section 3 of RFC 3550 is clear that a participant can use transport  
addresses to distinguish different RTP sessions, but that the  
distinguishing feature of a session is a shared SSRC space. It's  
entirely possible for a single RTP session to span multiple transport- 
layer connections, with different source and destination addresses and  
ports.

- The term "SSRC-multiplexing" is not clearly defined. I would  
recommend it be avoided throughout.

- It clear what is meant by an "SSM session" in this context,  
especially the statement "it is still possible for an SSM session to  
carry multiple RTP sessions each carrying multiple SSRC-multiplexed  
RTP streams".

- What is meant by "The RTP receiver multiplexes this unicast RTP  
session with the primary multicast RTP session is receives as part of  
the SSM session"?

Overall, section 1.1 can be read to suggest that the retransmission  
flows comprise a separate RTP session to the primary multicast flows,  
yet this doesn't seem compatible with some later design choices. For  
example, Section 6.3 discusses sending synchronisation information  
relating to the primary RTP session as a header extension in the burst  
RTP packets (i.e. the header extension is copied from the primary  
multicast RTP packets to the retransmission burst packets). This would  
seem to imply a shared SSRC space between primary and retransmission/ 
burst flows (i.e., a single RTP session), yet the last paragraph of  
section 1.1 can be read as requiring a separate RTP session for the  
burst traffic. If the retransmissions are sent in a separate RTP  
session, the header extensions must relate to the SSRC of the  
retransmission source, and so cannot be directly copied from the  
primary stream (the SSRC won't match, and there will be a different  
random offset to the RTP timestamp).

Section 7.3, 2nd paragraph: again, the implication is that a single  
RTP session is used for the primary and burst/retransmission flows,  
since the SSRC of the primary flow is used, and a shared SSRC space is  
the very definition of an RTP session.

Other points, not related to the RTP session definition:

- Section 6.2 (page 15): this section, and the rest of the draft,  
would be clearer if the feedback target, retransmission source, and  
burst source were explicitly distinguished in the text.

- Page 20: I would recommend avoiding the term "payload type  
multiplexing", since it can cause confusion with "SSRC multiplexing"  
and different RTP sessions. Simply note that preamble packets and  
media packets in the burst may use different RTP payload types.

- Page 22 (point 9, 2nd paragraph): can't an RTP_Rx that wants to  
terminate the session early get the SSRC from the RTP data packets  
it's receiving?

- I'm unconvinced by the handling of the SSRC in the RAMS-R requests.  
That the SSRC is sometimes valid, and sometimes ignored is  
undesirable. Can't the sender of the RAMS-R message always include its  
own SSRC in the header, and use the requested media SSRC field?

Thanks, and apologies for the lateness of these comments.

-- 
Colin Perkins
http://csperkins.org/

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 12 Apr 2010 11:46:37 +0200

Hi Colin,

Many of your comments have to do with the way the (unicast)
retransmission/burst packet stream is multiplexed with the primary SSM
RTP session in the RAMS draft.  The RAMS draft builds on RFC 4588. The
RFC 4588 defines session muxing and SSRC muxing, so I guess that means
that you see a conflict there as well.  
Amongst others, the RFC 4588 mandates that SSRC is the same for a
retransmission stream that is session multiplexed with a original stream
(using different transport address). It is true though, that there is no
hard rationaly in this RFC why this was decided as such.
In the RAMS draft the retransmission session is indeed a session
different from the SSM RTP session, but having a shared SSRC does not
necessarily mean this results in one single, same session, when one
mandates/defines the SSRC to be the same. IMO this is not in conflict
with RFC 3550 stating that a shared SSRC space is the very definition of
an RTP session.

Your comment related to Section 6.3 that sending synchronisation
information relating to the primary RTP session as a header extension in
the burst RTP packets (i.e. the header extension is copied from the
primary multicast RTP packets to the retransmission burst packets)
implies that the unicast burst packets and the SSM together  make one
single session, is IMHO not correct, (we simply follow the rule that
extension headers in the SSM original packets must be part of the
retransmission-formatted packets), but it would not hurt there is text
that warns on the interpretation of this data, in line with your
comments.

Regards
Tom  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Colin Perkins
Sent: zondag 11 april 2010 21:51
To: IETF AVT WG
Subject: [AVT] Comments on draft-ietf-avt-rapid-acquisition-for-rtp-08

I've reviewed draft-ietf-avt-rapid-acquisition-for-rtp-08.txt, and have
some comments. Mainly, the draft is unclear whether the unicast RAMS and
retransmission traffic shares the same SSRC space as the multicast media
stream, and hence is part of the same RTP session, or if it's a separate
RTP session with its own SSRC space. Either approach can be made to
work, I believe, but it affects the design and implementation choices,
and the lack of clarity throughout the draft is likely to cause
interoperability problems.

- The term "SSRC-multiplexing" is not clearly defined. I would recommend
it be avoided throughout.

- It clear what is meant by an "SSM session" in this context, especially
the statement "it is still possible for an SSM session to carry multiple
RTP sessions each carrying multiple SSRC-multiplexed RTP streams".

retransmission source, and so cannot be directly copied from the primary
stream (the SSRC won't match, and there will be a different random
offset to the RTP timestamp).

Section 7.3, 2nd paragraph: again, the implication is that a single RTP
session is used for the primary and burst/retransmission flows, since
the SSRC of the primary flow is used, and a shared SSRC space is the
very definition of an RTP session.

- Section 6.2 (page 15): this section, and the rest of the draft, would
be clearer if the feedback target, retransmission source, and burst
source were explicitly distinguished in the text.

- Page 20: I would recommend avoiding the term "payload type
multiplexing", since it can cause confusion with "SSRC multiplexing"  
and different RTP sessions. Simply note that preamble packets and media
packets in the burst may use different RTP payload types.

- Page 22 (point 9, 2nd paragraph): can't an RTP_Rx that wants to
terminate the session early get the SSRC from the RTP data packets it's
receiving?

- I'm unconvinced by the handling of the SSRC in the RAMS-R requests.  
That the SSRC is sometimes valid, and sometimes ignored is undesirable.
Can't the sender of the RAMS-R message always include its own SSRC in
the header, and use the requested media SSRC field?

--
Colin Perkins
http://csperkins.org/

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 12 Apr 2010 06:37:47 -0700

Hi Colin,

Tom did a good job in explaining our rationale. Since the beginning, we repeatedly said that retransmission and primary sessions were different sessions. They have different RTCP sessions as well. Based on this, the text is not conflicting IMO.

...
> source were explicitly distinguished in the text.

After the 1st wglc, I believe we did a careful revision to fix these. Do you see any inconsistency or incorrect text? I will check again as well but it would be useful to point out problematic places.
 
> packets in the burst may use different RTP payload types.

Such preamble packets share the same SSRC and thus seqnum space. So, they have to use different PT values to be differentiated. BTW, the preamble text in RAMS will be revised/deleted anyway per WG's decision.
 
> terminate the session early get the SSRC from the RTP data packets it's

Sure. The text says RAMS-I since it is supposed to be the first packet but we should add media packets as well.
 
> That the SSRC is sometimes valid, and sometimes ignored is undesirable.

If the client knows the SSRC, it puts it in the media sender SSRC field. If it does not know, it puts its own SSRC there to minimize the chances of a conflict. 

> the header, and use the requested media SSRC field?

I tend to agree, but the reason we kept it this way I believe was to use the default "media sender SSRC" field as much as possible. But, I am fine either way. We can make the "requested media sender ssrc(s)" field mandatory. If its length is zero, it will mean "send me everything in this RTP session", if there are specific SSRCs, it will mean "send me the ones with these SSRCs."

What does WG think about this?

-acbegen

---

From: Colin Perkins <[email-masked]>
Date: Tue, 13 Apr 2010 14:36:37 +0100

Tom,

On 12 Apr 2010, at 10:46, VAN CAENEGEM Tom wrote:
> retransmission/burst packet stream is multiplexed with the primary  
> SSM RTP session in the RAMS draft.  The RAMS draft builds on RFC  
> 4588. The RFC 4588 defines session muxing and SSRC muxing, so I  
> guess that means that you see a conflict there as well.

The definitions in RFC 4588 are problematic, yes. RFC 4588 would be  
much simpler, and would fit better with RFC 3550, if it's so-called  
"session-multiplexing" was allowed to use a randomly chosen SSRC and  
associated with the original session through the CNAME. That would, I  
think remove all the differences in handling between SSRC-multiplexing  
and session-multiplexing.

> retransmission stream that is session multiplexed with a original  
> stream (using different transport address). It is true though, that  
> there is no hard rationaly in this RFC why this was decided as such.  
> different from the SSM RTP session, but having a shared SSRC does  
> not necessarily mean this results in one single, same session, when  
> one mandates/defines the SSRC to be the same. IMO this is not in  
> conflict with RFC 3550 stating that a shared SSRC space is the very  
> definition of an RTP session.

It break SSRC collision detection, at least.

> information relating to the primary RTP session as a header  
> extension in the burst RTP packets (i.e. the header extension is  
> copied from the primary multicast RTP packets to the retransmission  
> burst packets) implies that the unicast burst packets and the SSM  
> together  make one single session, is IMHO not correct, (we simply  
> follow the rule that extension headers in the SSM original packets  
> must be part of the retransmission-formatted packets), but it would  
> not hurt there is text that warns on the interpretation of this  
> data, in line with your comments.

Having one RTP session reporting on another via RTCP is, IMHO,  
extremely problematic architecturally. RFC 4588 does not do this, and  
neither do I believe any other RFCs.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Tue, 13 Apr 2010 14:44:51 +0100

Hi Ali,

On 12 Apr 2010, at 14:37, Ali C. Begen (abegen) wrote:
> Tom did a good job in explaining our rationale. Since the beginning,  
> we repeatedly said that retransmission and primary sessions were  
> different sessions. They have different RTCP sessions as well. Based  
> on this, the text is not conflicting IMO.

I think the text confusing. It also seems that the RTCP sessions are  
conflated with the synchronisation messages.

> After the 1st wglc, I believe we did a careful revision to fix  
> these. Do you see any inconsistency or incorrect text? I will check  
> again as well but it would be useful to point out problematic places.

Section 6.2 states that the term Retransmission Server will be used to  
refer to the combined functionality. If the text has been fixed, then  
that statement should be removed.

>> multiplexing", since it can cause confusion with "SSRC  
>> multiplexing" and different RTP sessions. Simply note that preamble  
>> packets and media packets in the burst may use different RTP  
>> payload types.
>
> Such preamble packets share the same SSRC and thus seqnum space. So,  
> they have to use different PT values to be differentiated. BTW, the  
> preamble text in RAMS will be revised/deleted anyway per WG's  
> decision.

They don't have to use a different payload type, since the same  
payload format could be used for both preamble data and burst data.  
However, if they use a different payload format, then a different  
payload type has to be used. This is the standard RTP behaviour -  
there is nothing special or unusual here - but calling this "payload  
type multiplexing" makes it seem special.

> Sure. The text says RAMS-I since it is supposed to be the first  
> packet but we should add media packets as well.
>
>> undesirable.
> If the client knows the SSRC, it puts it in the media sender SSRC  
> field. If it does not know, it puts its own SSRC there to minimize  
> the chances of a conflict.
>
> I tend to agree, but the reason we kept it this way I believe was to  
> use the default "media sender SSRC" field as much as possible. But,  
> I am fine either way. We can make the "requested media sender  
> ssrc(s)" field mandatory. If its length is zero, it will mean "send  
> me everything in this RTP session", if there are specific SSRCs, it  
> will mean "send me the ones with these SSRCs."
>

-- 
Colin Perkins
http://csperkins.org/