Subject: [AVTCORE] Topologies-update, reply to Bo's review

From: Stephan Wenger <[email-masked]>
Date: Thu, 7 Aug 2014 23:14:28 +0000

Hi all,

You may have noticed that I just posted version -03 of the
topologies-update draft.  The main changes are alignment with the
terminology used in avtext’s grouping taxonomy draft, and a rewrite of
section 3.10 (split-component terminal).

As per guidance received in Toronto, I did include copy-pastes of those
few definitions of the taxonomy draft required herein, so to keep the two
drafts independent.  However, I have also asked the RFC editor to replace
those definitions with a reference to a forthcoming taxonomy-RFC, if such
can be done without undue delay.  See section 2.2.

Section 3.10 was close to unparsable--at least very confusing--which
triggered the rewrite.  I think it’s better now, but it certainly needs a
fresh review.

Towards the end of this email, find my responses to Bo Burman’s thorough
review of version -02, posted to this list on 6/11/14.  I had private
communication with Bo during the editing process, and he’s happy with the
result and found his points addressed.

My list of open issues of this draft is now empty.  WGLC would be fine
with me.  Please review, comment, and get this thing out of the door.

Thanks,
Stephan

On 6/11/14, 2:39 AM, "Bo Burman" <[email-masked]> wrote:

Hi all,

[Bo] I reviewed this as a part of the ongoing update of the taxonomy draft
to
try to align them, and have the following comments on the
topologies-update-02:
* What is meant with "Media Flow" in 3.2.1.3; is it a set of RTP Streams?
In that case, does this set have any specific characteristics?

[StW]

The comments relates to the description of Fig. 3.  No, the ³media flow²
is really only a single RTP stream (without FEC) to which FEC is added by
the translator.  The relevant paragraph was poorly and overly broadly
written, and I tightened the language.

[Bo]
* (At least) in 3.2.2 and 3.3.3, the term "flow" is used in "RTP flow" or
"packet flow"; how is that different from taxonomy RTP Stream?

[StW]
Very good catch; the language here (mostly from 5117) was really in need
to be tightened up.  I checked the various occurrences of ³flow², and
replaced them with ³RTP stream² where appropriate.  The remaining ³flow²s
are transport flows, which is basically the flow of packets in a transport
association (five tuple).

[Bo]
* The terms "transport flow" or just "flow" are heavily used in 3.4;
again, as with "Media Flow", is there any specific distinction assumed in
this besides possibly being a set of RTP Streams?

[StW]
Yes, in 3.4, transport flow refers to packets going over a 5 tuple, see
above.  I hope this is now clear from context.

[Bo]
* The term "RTP media stream" is used in many places; is there an
intended specialization compared to a (generic) RTP Stream?

[StW]
No, RTP media stream and RTP stream are meant to be the same in all cases.
I went through the doc and fixed as appropriate, using ³RTP stream²
(hopefully) consistently.

[Bo]
* What is a "Content source" in 3.6? Is it a Media Source?

[StW]
Tricky.  In 3.6, ³content source² is used to identify the Media sender as
a whole: uncompressed stream generation (through mixing or acquisition),
encoding, packetizing.   ³Endpoint² may be more appropriate.  However,
that would imply that a middlebox like a Mixer or MCU are also endpoints,
which is counter-intuitive, at least to me.  I tried to word around.

[Bo]
* What is a "Conference session" in 3.6? Is it a Communication Session,
or some specialization of it?

[StW]
Communication Session seems right.

[Bo]
* Can you explain a bit of what is a "Session participant" in 3.6? There
are discussions on the use of End Point and/or Participant in taxonomy,
so I'm hesitant to suggest any taxonomy term right now since it may
change.

[StW]
Session participants refers to RTP sending/receiving entities that take
part of the same RTP session.  Insofar, taxonomy-02¹s End Point would be
appropriate, with the additional remark that these End Points share one
RTP session.

The word ³participant² is used throughout the document in a number of
different contexts, usually but not always with a meaning similar to End
Point in taxonomy.  I have replaced ³participant² with ³End Point² where
appropriate, and left it (usually with qualifiers) otherwise.

[Bo]
* The stand-alone term "stream" is used in many places throughout the
document. I think it very reasonable to just assume it is a short for
"RTP Stream", but you may want to make such comment early on in the
document. I found no place in the document where such assumption would be
invalid.

[StW]
Fixed by using ³RTP stream consistently.

[Bo]
* The term "global session" is used in 3.6; I find it a bit hard to
understand what is meant.

[StW]
I think it¹s ³Communication Session² (every Endpoint and every middle box
that are talking to each other).  Fixed.

[Bo]
* Section 3.6.1 could possibly benefit from using the taxonomy term
"Encoded Stream"

[StW]
Correct.  Clarified.

[Bo]
* Nit: Figure 3 (in 3.2.1.3) and Figure 4 (in 3.2.2) have the same
caption; is this intended?

[StW]
No.  Fixed.

---

From: Colin Perkins <[email-masked]>
Date: Fri, 8 Aug 2014 14:59:55 +0100

Stephan,

The new text in 3.10 confuses me: why can’t the subunits be part of a common RTP session? You have:

   +---------------------+
   | Endpoint A          |
   | Local Area Network  |
   |      +------------+ |
   |   +->| Audio      |<+-RTP---\
   |   |  +------------+ |        \    +------+
   |   |  +------------+ |         +-->|      |
   |   +->| Video      |<+-RTP-------->|  B   |
   |   |  +------------+ |         +-->|      |
   |   |  +------------+ |        /    +------+
   |   +->| Control    |<+-SIP---/
   |      +------------+ |
   +---------------------+

If B sends reception reports so that the audio part of A can see the SSRCs used by the video and Control parts of A, then you have a single RTP session.

I agree that a single RTP session isn’t required here, but it doesn’t seem to be prohibited.

Cheers,
Colin

On 8 Aug 2014, at 00:14, Stephan Wenger <[email-masked]> wrote:
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

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

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 8 Aug 2014 14:30:46 +0000

Hi Colin,

The two RTP subunits (Audio and Video) share the same CNAME, as they are
semantically coupled, and they use distinct transport addresses.  These
are the distinguishing features of this terminal’s topology.  In that
case, Audio and Video would at least violate a “SHOULD” clause of RFC 3550
(section 6.5.1, first bullet on page 47) if they were in the same RTP
session, no?

A different advise would be to say that if one decomposes an endpoint, a
good choice of the CNAME would be something like
[email-masked] and
[email-masked], rather than using
[email-masked] as CNAME for both Audio and Video.
So, distinct CNAMEs, but still human-observable semantic coupling (even a
reasonably smart machine could figure it out if configured correctly :-)

Should I add this as a sensible design alternative?  Or am I in the woods?

Stephan

On 8/8/14, 6:59 AM, "Colin Perkins" <[email-masked]> wrote:

>If B sends reception reports so that the audio part of A can see the
>SSRCs used by the video and Control parts of A, then you have a single
>RTP session.
>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 8 Aug 2014 15:36:46 +0100

Hi,

They’re logically part of the same endpoint, and use a common clock, and this makes them semantically coupled anyway, so I think a common CNAME and single RTP session makes sense (this is essentially the design the old Mbone tools used to lip-sync when audio and video were done with separate tools, using a coordination protocol). 

Colin

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

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 8 Aug 2014 14:37:06 +0000

Uh, replace the “John.Doe” with the 96 bits of RFC 7022, please.  But
leave the “.audio" and “.video"
Stephan

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 8 Aug 2014 15:20:20 +0000

Hi Colin,

On 8/8/14, 7:36 AM, "Colin Perkins" <[email-masked]> wrote:

>Hi,
>
>They’re logically part of the same endpoint, and use a common clock, and
>this makes them semantically coupled anyway, so I think a common CNAME
>and single RTP session makes sense (this is essentially the design the
>old Mbone tools used to lip-sync when audio and video were done with
>separate tools, using a coordination protocol).

So let’s assume a common CNAME, but also separate transport addresses per
subunit.  Both version 02 and 03 of the draft comment on that scenario as
follows:

“It is not really feasible to decompose one logical end-point into two
different transport nodes in one RTP session.  A third party monitor would
report such an attempt as two entities being two different end-points with
a CNAME collision.  As a result, a fully RTP conformant de-composited
endpoint is one where the different decomposed parts use separate RTP
sessions to send and/or receive media streams intended for them."

You seem to assert that this is a non-issue.  Why?

Stephan

>>>> triggered the rewrite.  I think it’s better now, but it certainly
>>>>needs
>>>> a
>>>> fresh review.
>>>>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 8 Aug 2014 18:22:21 +0100

Hi,

> You seem to assert that this is a non-issue.  Why?

I think you’re confusing transport-layer flows and RTP sessions, and the role of the CNAME. It’s a non-issue because the “CNAME collision” is normal, and orthogonal to the number of RTP sessions or transport-layer flows.

Assume I want to send you audio and video flows that can be synchronised on playout. I’ll send two RTP streams, one for the audio and one for the video, using a different SSRC for each stream, and mapping their media clocks to a common reference clock, which is reported in RTCP SR packets. The RTCP SDES packets for each SSRC will use the same CNAME, and it’s that common CNAME that indicates to the receiver that the two flows can be synchronised. The receiver also has its own two SSRC values, one for the audio and one for video, that it includes in the RTCP RR packets it sends (and also for any audio and video RTP packets it sends back).

The RTP streams can be multiplexed onto a single 5-tuple, for example:

 Sender                      Receiver
 +-------------------+       +------------------+    
 | IP addr 10.0.0.1  |       | IP addr 10.0.0.2 |
 |                   |       |                  |
 | +-----+SSRC 1111  |       | SSRC 3333+-----+ |
 | |Audio|<-----+    |       |    +---->|Audio| |
 | +-----+      |Port|       |Port|     +-----+ |
 |              +====+=======+====+             |
 | +-----+      |5000|       |6000|     +-----+ |
 | |Video|<-----+    |       |    +---->|Video| |
 | +-----+SSRC 2222  |       | SSRC 4444+-----+ |
 |                   |       |                  |
 +-------------------+       +------------------+

There is a single transport-layer flow, from 10.0.0.1:5000 to 10.0.0.2:6000. RTP packets with two SSRC values are multiplexed on that flow from sender to receiver, and RTCP packets with two SSRC values are multiplexed on that flow in the reverse direction. In this case, both SSRCs at the receiver can see the packets sent by both sender SSRCs, since they all arrive on the same port. The RTCP sent by SSRC 3333 will contain RTCP RR packets relating both to SSRC 1111 and SSRC 2222, as will the RTCP sent by SSRC 4444. This gives a single RTP session, since each SSRC can see every other SSRC. The RTCP reports sent by SSRC 1111 and SSRC 2222 will both use the same CNAME, to indicate that they can be synchronised.

The RTP streams can also be sent using distinct 5-tuples, for example:

 Sender                      Receiver
 +-------------------+       +------------------+    
 | IP addr 10.0.0.1  |       | IP addr 10.0.0.2 |
 |                   |       |                  |
 | +-----+ Port 5000 |       |Port 6000 +-----+ |
 | |Audio|-----------+-------+--------->|Audio| |
 | +-----+ SSRC 1111 |       |SSRC 3333 +-----+ |
 |                   |       |             :    |
 | +-----+ Port 5002 |       |Port 6002 +-----+ |
 | |Video|-----------+-------+--------->|Video| |
 | +-----+ SSRC 2222 |       |SSRC 4444 +-----+ |
 |                   |       |                  |
 +-------------------+       +------------------+

This has two transport-layer flows, one from 10.0.0.1:5000 to 10.0.0.2:6000, and the other from 10.0.0.1:5002 to 10.0.0.2:6002. One of those flows carries audio, the other carries video.

If SSRC 3333 only sends RTCP reports relating to SSRC 1111, and SSRC 4444 only sends RTCP reports relating to SSRC 2222, then this scenario comprises two RTP sessions. However, if the receiver is implemented such that SSRC 3333 and SSRC 4444 share reception quality information, and each of SSRC 3333 and SSRC 4444 send RTCP reports relating to both SSRC 1111 and SSRC 2222, then there is only a single RTP session, despite the use of multiple transport-layer flows, since each SSRC can see every other SSRC. 

No matter whether how the receiver is implemented, RTCP packets sent by SSRC 1111 and by SSRC 222 will use the same CNAME, to indicate that they can be synchronised, even though they are sent on separate transport-layer flows.

We can split things up further, to the distinct 5-tuples come from different IP addresses (this is a version of Topo-Split-Terminal):

 Sender                      Receiver
 +-------------------+       +------------------+    
 | IP addr 10.0.0.1  |       | IP addr 10.0.0.2 |
 |                   |       |                  |
 | +-----+ Port 5000 |       |Port 6000 +-----+ |
 | |Audio|<----------+-------+--------->|Audio| |
 | +-----+ SSRC 1111 |       |SSRC 3333 +-----+ |
 +---+---------------+       |             :    |
     |clock sync             |             :    |
 +---+---------------+       |             :    |
 | IP addr 10.0.1.1  |       |             :    |
 | +-----+ Port 5002 |       |Port 6004 +-----+ |
 | |Video|<----------+-------+--------->|Video| |
 | +-----+ SSRC 2222 |       |SSRC 4444 +-----+ |
 |                   |       |                  |
 +-------------------+       +------------------+

Again, there are two transport layer flows, and again this can be either one or two RTP sessions, depending on whether the two SSRCs in the Receiver share information (i.e., if the RTCP packets that SSRC 3333 sends include reports relating to both SSRC 1111 and SSRC 2222, and similarly for SSRC 4444, then each SSRC can see every other, and there is a single RTP session; however, if SSRC 3333 only reports on SSRC 1111, and SSRC 4444 only reports on SSRC 2222, then there are two RTP sessions). Again, irrespective of receiver behaviour, and the number of RTP sessions, RTCP packets sent by SSRC 1111 and SSRC 2222 will use the same CNAME to indicate that their flows can be synchronised (they need to run a clock synchronisation protocol to ensure they have access to the common clock).

If you want to decompose an endpoint, sending audio and video from separate transport-layer addresses and allowing the receiver to synchronise the flows, then the audio and video need to use different SSRCs, but the same CNAME, and use some (non-RTP) clock synchronisation protocol. Whether those flows form a single RTP session or not depends on whether the system is implemented to share a single SSRC space and single view of the reception quality, or not. Topo-Split-Terminal can therefore be implemented using multiple RTP sessions, or using a single RTP session (although neither affects the choice of CNAME).

I would argue that implementing this topology as a single RTP session could be beneficial, since the cross reporting provides information that’s helpful for (potentially automated) debugging of reception quality problems. Others would doubtless say the cross-reporting is unnecessary overhead, and would prefer to implement this as separate RTP sessions. Both are valid views, with different trade-offs.

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

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 8 Aug 2014 17:45:38 +0000

Hi Colin,
I think I start seeing your point.  Let me work on section 3.10 a bit more
(over the weekend most likely).
But please also see inline (towards the top of the thread only).
Thanks,
Stephan

On 8/8/14, 10:22 AM, "Colin Perkins" <[email-masked]> wrote:

>>> They¹re logically part of the same endpoint, and use a common clock,
>>>and
>> So let¹s assume a common CNAME, but also separate transport addresses
>>per
>> ³It is not really feasible to decompose one logical end-point into two
>> different transport nodes in one RTP session.

This is the statement you question.  You argue it is possible and still
stay compliant with RTP.

>>A third party monitor would
>> a CNAME collision.

Do I understand you correctly that yes, a third party monitor would indeed
report a CNAME collision, but that¹s a problem of the third party monitor.
 Or, better, the third party monitor¹s lack of awareness of the existence
of decomposed endpoint subunits in the same RTP session, them being a
legal (and, in at least some scenarios, even desirable) design choice.

>>As a result, a fully RTP conformant de-composited

And this is, according to you, an incorrect statement.

>I think you¹re confusing transport-layer flows and RTP sessions, and the
>role of the CNAME. It¹s a non-issue because the ³CNAME collision² is
>normal, and orthogonal to the number of RTP sessions or transport-layer
>flows.
>
>Assume I want to send you audio and video flows that can be synchronised
>on playout. I¹ll send two RTP streams, one for the audio and one for the
>video, using a different SSRC for each stream, and mapping their media
>clocks to a common reference clock, which is reported in RTCP SR packets.
>The RTCP SDES packets for each SSRC will use the same CNAME, and it¹s
>that common CNAME that indicates to the receiver that the two flows can
>be synchronised. The receiver also has its own two SSRC values, one for
>the audio and one for video, that it includes in the RTCP RR packets it
>sends (and also for any audio and video RTP packets it sends back).
>
>There is a single transport-layer flow, from 10.0.0.1:5000 to
>10.0.0.2:6000. RTP packets with two SSRC values are multiplexed on that
>flow from sender to receiver, and RTCP packets with two SSRC values are
>multiplexed on that flow in the reverse direction. In this case, both
>SSRCs at the receiver can see the packets sent by both sender SSRCs,
>since they all arrive on the same port. The RTCP sent by SSRC 3333 will
>contain RTCP RR packets relating both to SSRC 1111 and SSRC 2222, as will
>the RTCP sent by SSRC 4444. This gives a single RTP session, since each
>SSRC can see every other SSRC. The RTCP reports sent by SSRC 1111 and
>SSRC 2222 will both use the same CNAME, to indicate that they can be
>synchronised.
>
>This has two transport-layer flows, one from 10.0.0.1:5000 to
>10.0.0.2:6000, and the other from 10.0.0.1:5002 to 10.0.0.2:6002. One of
>those flows carries audio, the other carries video.
>
>If SSRC 3333 only sends RTCP reports relating to SSRC 1111, and SSRC 4444
>only sends RTCP reports relating to SSRC 2222, then this scenario
>comprises two RTP sessions. However, if the receiver is implemented such
>that SSRC 3333 and SSRC 4444 share reception quality information, and
>each of SSRC 3333 and SSRC 4444 send RTCP reports relating to both SSRC
>1111 and SSRC 2222, then there is only a single RTP session, despite the
>use of multiple transport-layer flows, since each SSRC can see every
>other SSRC. 
>
>No matter whether how the receiver is implemented, RTCP packets sent by
>SSRC 1111 and by SSRC 222 will use the same CNAME, to indicate that they
>can be synchronised, even though they are sent on separate
>transport-layer flows.
>
>We can split things up further, to the distinct 5-tuples come from
>different IP addresses (this is a version of Topo-Split-Terminal):
>
> Sender                      Receiver
>Again, there are two transport layer flows, and again this can be either
>one or two RTP sessions, depending on whether the two SSRCs in the
>Receiver share information (i.e., if the RTCP packets that SSRC 3333
>sends include reports relating to both SSRC 1111 and SSRC 2222, and
>similarly for SSRC 4444, then each SSRC can see every other, and there is
>a single RTP session; however, if SSRC 3333 only reports on SSRC 1111,
>and SSRC 4444 only reports on SSRC 2222, then there are two RTP
>sessions). Again, irrespective of receiver behaviour, and the number of
>RTP sessions, RTCP packets sent by SSRC 1111 and SSRC 2222 will use the
>same CNAME to indicate that their flows can be synchronised (they need to
>run a clock synchronisation protocol to ensure they have access to the
>common clock).
>
>If you want to decompose an endpoint, sending audio and video from
>separate transport-layer addresses and allowing the receiver to
>synchronise the flows, then the audio and video need to use different
>SSRCs, but the same CNAME, and use some (non-RTP) clock synchronisation
>protocol. Whether those flows form a single RTP session or not depends on
>whether the system is implemented to share a single SSRC space and single
>view of the reception quality, or not. Topo-Split-Terminal can therefore
>be implemented using multiple RTP sessions, or using a single RTP session
>(although neither affects the choice of CNAME).
>
>I would argue that implementing this topology as a single RTP session
>could be beneficial, since the cross reporting provides information
>that¹s helpful for (potentially automated) debugging of reception quality
>problems. Others would doubtless say the cross-reporting is unnecessary
>overhead, and would prefer to implement this as separate RTP sessions.
>Both are valid views, with different trade-offs.
>
>-- 
>Colin Perkins
>http://csperkins.org/
>
>
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 11 Aug 2014 10:43:33 +0100

Hi Stephan,

[inline]

On 8 Aug 2014, at 18:45, Stephan Wenger <[email-masked]> wrote:
>>> per subunit.  Both version 02 and 03 of the draft comment on that scenario
>>> as follows:
>>> 
>>> A third party monitor would report such an attempt as two entities being two different end-points with a CNAME collision.
> 

Correct. A “CNAME collision” is not a problem in RTP. Two SSRCs sending media with the same CNAME from different source address/port pairs is perfectly legal.

> legal (and, in at least some scenarios, even desirable) design choice.

Right. This can also occur with multi-homed endpoints, sending media using multiple interfaces. 

> And this is, according to you, an incorrect statement.

No. The RTP streams generated by a decomposed endpoint can from a single RTP session, or they can form multiple RTP sessions. Whether they do so or not depends on SSRC visibility, and is orthogonal to the choice of CNAME (since they’ll always use a single CNAME) or the number of transport layer flows.

Cheers,
Colin