Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt

From: Colin Perkins <[email-masked]>
Date: Mon, 1 Dec 2014 14:53:27 +0000

I’ve read this draft, and have a few generally minor comments. Overall, though, I do think this draft is in very good shape.

Section 2.1.10: 
- “Each RTP stream defines a unique RTP sequence numbering and timing space” - should be “each SSRC defines”, since a change in SSRC requires a new random offset to sequence number and timestamp.

- Last two bullet points should perhaps be “Several RTP Streams, each with their own SSRC, …” for clarity?

Section 2.1.13:
- “Each transport association normally contains only a single RTP session…”: agree, but it might be appropriate to mention that the opposite isn’t true, and RTP sessions can span multiple transport associations.

Figure 6:
- The figure might benefit from having a “synchronisation context” included?

Section 2.2.1:
- Has an “Editor’s note” that should be removed

Section 2.2.2:
- Editor’s note: I think it does make sense to talk about an RTP session as a Communication Entity. 

- The 4th bullet point is confusing. I think here, and also in section 2.1.13, it might be clearer to say that a single media transport always carries a single RTP session, and to describe draft-westerlund-avtcore-transport-multiplexing as a way of carrying multiple transport associations over a single port.

- Last bullet point - can you give some examples?

Section 2.2.3:
- “can have several multimedia sessions” -> “can participate in”
- “Can have several associated” -> “can be comprised of”

Section 2.2.5:
- This seems to prohibit a communication session with, e.g., just a single audio flow.

Section 3.1.4:
- How does an m= line relate to the other terms defined here?

Section 3.6:
- “Example to such codecs are” -> “Examples of codecs that support multi-channel audio are”

Section 3.8:
- Delete “i.e., a different RTP session” just before Figure 8, since the separate media transport is not necessarily part of a different RTP session (although I agree it usually is).

Cheers,
Colin

On 14 Nov 2014, at 17:31, DRAGE, Keith (Keith) <[email-masked]> wrote:

> (As WG cochair) 
> 
> This is to start a working group last call on draft-ietf-avtext-rtp-grouping-taxonomy-03.
> 
> To cater for the end of the IETF meeting, and for various national holidays, this working group last call will last three weeks.
> 
> Therefore please comment on this document by Friday 5th December 2014.
> 
> Please send comments to the working group list.
> 
> It is helpful to give some assessment of the nature of your comment, as to whether you regard it as editorial, minor technical, or a rather more major flaw.
> 
> Regards
> 
> Keith
> 
> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 14 November 2014 12:05
> To: [email-masked]
> Cc: [email-masked]
> Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF.
> 
>        Title           : A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources
>        Authors         : Jonathan Lennox
>                          Kevin Gross
>                          Suhas Nandakumar
>                          Gonzalo Salgueiro
>                          Bo Burman
> 	Filename        : draft-ietf-avtext-rtp-grouping-taxonomy-03.txt
> 	Pages           : 42
> 	Date            : 2014-11-14
> 
> Abstract:
>   The terminology about, and associations among, Real-Time Transport
>   Protocol (RTP) sources can be complex and somewhat opaque.  This
>   document describes a number of existing and proposed relationships
>   among RTP sources, and attempts to define common terminology for
>   discussing protocol entities and their relationships.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-03
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-grouping-taxonomy-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

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

---

From: Bo Burman <[email-masked]>
Date: Tue, 2 Dec 2014 15:39:59 +0000

Hi Colin,

Thank you for the review! Comments inline.

Cheers,
Bo

> From: avtext [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: den 1 december 2014 15:53
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt
> 
> I've read this draft, and have a few generally minor comments. Overall, though, I do think this draft is in very good shape.
> 
> Section 2.1.10:
> - "Each RTP stream defines a unique RTP sequence numbering and timing space" - should be "each SSRC defines", since a
> change in SSRC requires a new random offset to sequence number and timestamp.
[BoB] True. What about "Each SSRC (even for a single RTP stream, see above) defines a unique..." to hopefully be even more clear in connecting that statement back to what applies to an RTP Stream?

> 
> - Last two bullet points should perhaps be "Several RTP Streams, each with their own SSRC, ..." for clarity?
[BoB] OK

> 
> Section 2.1.13:
> - "Each transport association normally contains only a single RTP session...": agree, but it might be appropriate to mention
> that the opposite isn't true, and RTP sessions can span multiple transport associations.
[BoB] Good idea.

> 
> Figure 6:
> - The figure might benefit from having a "synchronisation context" included?
[BoB] Maybe, but that is not part of the section where Figure 6 is included! I also have somewhat of a problem how to depict it, especially since I don't want the picture to become clobbered. Do you have any concrete proposal in mind?

A synchronization context is, in that picture, basically a grouping of some (not necessarily all) individual RTP streams that are part of the indicated RTP sessions, carried by the indicated Media Transport(s), in a single direction. Such sample synchronization context can be a relation within a single Media Transport (which will be impossible to see without expanding the Media Transport arrow), or (easier to depict) a relation stretching across both indicated Media Transports, but at the same time not encompassing (no box around) the entire Media Transport.

One possible suggestion would be (not saying that I accepted to make this edit without at least some further discussion):

      +------------------------------------------------------------+
      | Communication Session                                      |
      |                                                            |
      | +----------------+                      +----------------+ |
      | | Participant A  |    +------------+    | Participant B  | |
      | |                |    | Multimedia |    |                | |
      | | +-------------+|<==>| Session    |<==>|+-------------+ | |
      | | | End Point A ||    |            |    || End Point B | | |
      | | |             ||    +------------+    ||             | | |
      | | | +-----------++----------------------++-----------+ | | |
      | | | |            |                      |            | | | |
      | | | | RTP Session|---Media Transport--->|            | | | |
      | | | | Audio      |<---Media Transport---|            | | | |
      | | | |            |          ^           |            | | | |
      | | | +-----------++----------|-----------++-----------+ | | |
      | | |             ||          v           ||             | | |
      | | |             || +-----------------+  ||             | | |
      | | |             || | Synchronization |  ||             | | |
      | | |             || |     Context     |  ||             | | |
      | | |             || +-----------------+  ||             | | |
      | | |             ||          ^           ||             | | |
      | | | +-----------++----------|-----------++-----------+ | | |
      | | | |            |          v           |            | | | |
      | | | | RTP Session|<---Media Transport---|            | | | |
      | | | | Video      |---Media Transport--->|            | | | |
      | | | |            |                      |            | | | |
      | | | +-----------++----------------------++-----------+ | | |
      | | +-------------+|                      |+-------------+ | |
      | +----------------+                      +----------------+ |
      +------------------------------------------------------------+

> 
> Section 2.2.1:
> - Has an "Editor's note" that should be removed
[BoB] Yes. See separate mail thread on that topic.

> 
> Section 2.2.2:
> - Editor's note: I think it does make sense to talk about an RTP session as a Communication Entity.
[BoB] Good. I do too, so I suggest to keep it here and remove the editor's note.

> 
> - The 4th bullet point is confusing. I think here, and also in section 2.1.13, it might be clearer to say that a single media
> transport always carries a single RTP session, and to describe draft-westerlund-avtcore-transport-multiplexing as a way
> of carrying multiple transport associations over a single port.
[BoB] Agree that this is probably a useful distinction to make. This will require a few text changes in both 2.1.13 and here in 2.2.2. I actually suggest that we describe that type of multiplexing only in 2.1.13 and keep silent about it in 2.2.2, only mentioning that a single Media Transport cannot carry more than a single RTP session.

> - Last bullet point - can you give some examples?
[BoB] I realize that "related" can there be taken to mean either conceptually related, for example originating from or targeted for the same endpoint or participant, or (implicitly) by containing RTP streams that are somehow related (synchronization context, dependency, redundancy, etc), or it can be taken as a suggestion that there exist some defined RTP session "handle" allowing for more concrete relation actions, which is in general not true.

I wonder if the very brief text in this bullet is in fact redundant, sufficiently discussed in section 3, and could be deleted here?

> 
> Section 2.2.3:
> - "can have several multimedia sessions" -> "can participate in"
> - "Can have several associated" -> "can be comprised of"
[BoB] OK

> - This seems to prohibit a communication session with, e.g., just a single audio flow.
[BoB] That was not the intent. I will clarify.

> - How does an m= line relate to the other terms defined here?
[BoB] I think that is elaborated in the existing term description section 4.2 "Media Description". I can cross reference that section here. Do you think that is sufficient, or do you want a more elaborate description here too?

> 
> Section 3.6:
> - "Example to such codecs are" -> "Examples of codecs that support multi-channel audio are"
[BoB] OK

> 
> Section 3.8:
> - Delete "i.e., a different RTP session" just before Figure 8, since the separate media transport is not necessarily part of a
> different RTP session (although I agree it usually is).
[BoB] OK

---

From: Colin Perkins <[email-masked]>
Date: Wed, 3 Dec 2014 11:49:44 +0000

Hi Bo,

Comments inline. This basically all looks good.

Cheers,
Colin

On 2 Dec 2014, at 15:39, Bo Burman <[email-masked]> wrote:
> [BoB] True. What about “Each SSRC (even for a single RTP stream, see above) defines a unique..." to hopefully be even more clear in connecting that statement back to what applies to an RTP Stream?

I don’t think that clarifies, especially given the preceding bullet point says that an RTP stream can have one and only one SSRC. The key characteristic is that the SSRC has a single sequence number and timestamp space; this is not true of an RTP stream, because the SSRC can change.

> [BoB] Maybe, but that is not part of the section where Figure 6 is included! I also have somewhat of a problem how to depict it, especially since I don't want the picture to become clobbered. Do yo…

I was going to suggest another box surrounding the RTP Session Audio and RTP Session Video, but I think your suggestion below is clearer.

> One possible suggestion would be (not saying that I accepted to make this edit without at least some further discussion):

This looks good to me.

> [BoB] Agree that this is probably a useful distinction to make. This will require a few text changes in both 2.1.13 and here in 2.2.2. I actually suggest that we describe that type of multiplexing…

Makes sense.

> I wonder if the very brief text in this bullet is in fact redundant, sufficiently discussed in section 3, and could be deleted here?

Or keep it, but add a forward reference to Section 3?

> [BoB] I think that is elaborated in the existing term description section 4.2 "Media Description". I can cross reference that section here. Do you think that is sufficient, or do you want a more el…

No, a cross reference to Section 4.2 would be enough. 

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

---

From: Bo Burman <[email-masked]>
Date: Wed, 3 Dec 2014 12:57:48 +0000

A few additional comments inline (removing parts of the conversation that was already agreed, for brevity)

Cheers,
Bo

> From: Colin Perkins [mailto:[email-masked]]
> Sent: den 3 december 2014 12:50
> To: Bo Burman
> Cc: DRAGE, Keith (Keith); [email-masked]
...snip...
> >> Section 2.1.10:
> >> - "Each RTP stream defines a unique RTP sequence numbering and timing
> >> space" - should be "each SSRC defines", since a change in SSRC requires a new random offset to sequence number
> and timestamp.
> > [BoB] True. What about "Each SSRC (even for a single RTP stream, see above) defines a unique..." to hopefully be even
> more clear in connecting that statement back to what applies to an RTP Stream?
> 
> I don't think that clarifies, especially given the preceding bullet point says that an RTP stream can have one and only one
> SSRC. The key characteristic is that the SSRC has a single sequence number and timestamp space; this is not true of an
> RTP stream, because the SSRC can change.
[BoB] OK. I'll just change according to your proposal then.

...snip...
> > [BoB] Maybe, but that is not part of the section where Figure 6 is included! I also have somewhat of a problem how to
> depict it, especially since I don't want the picture to become clobbered. Do you have any concrete proposal in mind?
> 
[BoB] OK. I can make that change, if you think it is useful.

Just a thought: is the Synchronization Context somehow more connected to (in this specific picture) Endpoint B, since the interrelation arrows point to Media Transports originating from there, and since that Synchronization Context is "created" by Endpoint B? I wonder if it would be useful to have the Synchronization Context box partially extend _into_ Endpoint B? Like (partial picture):

| | | | Audio      |<--Media Transport--|            | | | |
| | | |            |              ^     |            | | | |
| | | +-----------++--------------|-----++-----------+ | | |
| | |             ||              v     ||             | | |
| | |             ||        +-----------++----+        | | |
| | |             ||        | Synchronization |        | | |
| | |             ||        |     Context     |        | | |
| | |             ||        +-----------++----+        | | |
| | |             ||              ^     ||             | | |
| | | +-----------++--------------|-----++-----------+ | | |
| | | |            |              v     |            | | | |
| | | | RTP Session|<--Media Transport--|            | | | |

At the same time, the Synchronization Context is really _used_ in Endpoint A, so just extending it into Endpoint B is maybe not clarifying? Better then to keep it as a relation "on the wire" as originally suggested?

...snip...
> >> Section 2.2.2:
...snip...
> > [BoB] I realize that "related" can there be taken to mean either conceptually related, for example originating from or
> targeted for the same endpoint or participant, or (implicitly) by containing RTP streams that are somehow related
> (synchronization context, dependency, redundancy, etc), or it can be taken as a suggestion that there exist some
> defined RTP session "handle" allowing for more concrete relation actions, which is in general not true.
> >
[BoB] OK. I'll add some brief text along the lines suggested above with forward references to Section 3. I think just referencing Section 3 may not be that helpful.

...snip...
> > [BoB] I think that is elaborated in the existing term description section 4.2 "Media Description". I can cross reference
> that section here. Do you think that is sufficient, or do you want a more elaborate description here too?
> 
[BoB] OK

---

From: Colin Perkins <[email-masked]>
Date: Thu, 4 Dec 2014 12:36:45 +0000

Hi,

A couple of quick comments below. I think we’re pretty much in agreement.

Cheers,
Colin

On 3 Dec 2014, at 12:57, Bo Burman <[email-masked]> wrote:
> At the same time, the Synchronization Context is really _used_ in Endpoint A, so just extending it into Endpoint B is maybe not clarifying? Better then to keep it as a relation “on the wire" as originally suggested?

The synchronisation context is really at the sending side, since that’s where the mapping to the NTP-format clock is defined. However, the diagram shows bi-directional flows, so I’m not sure that helps. Leaving it in the middle of the diagram is probably easiest and clearest.

>>> [BoB] I realise that “related” can there be taken to mean either conceptually related, for example originating from or targeted for the same endpoint or participant, or (implicitly) by containing RTP streams that are somehow related (synchronization context, dependency, redundancy, etc), or it can be taken as a suggestion that there exist some defined RTP session "handle" allowing for more concrete relation actions, which is in general not true.
>>> 

Okay, but do keep it brief. I don’t think much is needed here.

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

---

From: Bo Burman <[email-masked]>
Date: Fri, 5 Dec 2014 09:49:10 +0000

"OK" to all of your comments below.

Cheers,
Bo

> Sent: den 4 december 2014 13:37
> To: Bo Burman
> A couple of quick comments below. I think we're pretty much in agreement.
> 
> Cheers,
> Colin
> 
> 
> 
> >> Subject: Re: [avtext] I-D Action:
> >> draft-ietf-avtext-rtp-grouping-taxonomy-03.txt
> >>
> >> Hi Bo,
> >>
> >>>> - "Each RTP stream defines a unique RTP sequence numbering and
> >>>> timing space" - should be "each SSRC defines", since a change in
> >>>> SSRC requires a new random offset to sequence number
> >> and timestamp.
> >>> [BoB] True. What about "Each SSRC (even for a single RTP stream, see
> >>> above) defines a unique..." to hopefully be even
> >> I don't think that clarifies, especially given the preceding bullet
> >> point says that an RTP stream can have one and only one SSRC. The key
> >> characteristic is that the SSRC has a single sequence number and timestamp space; this is not true of an RTP stream,
> because the SSRC can change.
> >>> [BoB] Maybe, but that is not part of the section where Figure 6 is
> >>> included! I also have somewhat of a problem how to
> >> I was going to suggest another box surrounding the RTP Session Audio
> >> and RTP Session Video, but I think your suggestion below is clearer.
> > Just a thought: is the Synchronization Context somehow more connected to (in this specific picture) Endpoint B, since
> the interrelation arrows point to Media Transports originating from there, and since that Synchronization Context is
> "created" by Endpoint B? I wonder if it would be useful to have the Synchronization Context box partially extend _into_
> Endpoint B? Like (partial picture):
> >
> > At the same time, the Synchronization Context is really _used_ in Endpoint A, so just extending it into Endpoint B is
> maybe not clarifying? Better then to keep it as a relation "on the wire" as originally suggested?
> 
> The synchronisation context is really at the sending side, since that's where the mapping to the NTP-format clock is
> defined. However, the diagram shows bi-directional flows, so I'm not sure that helps. Leaving it in the middle of the
> diagram is probably easiest and clearest.
> 
> > ...snip...
> >>>> Section 2.2.2:
> > ...snip...
> >>> [BoB] I realise that "related" can there be taken to mean either conceptually related, for example originating from or
> > [BoB] OK. I'll add some brief text along the lines suggested above with forward references to Section 3. I think just
> referencing Section 3 may not be that helpful.
> 
> Okay, but do keep it brief. I don't think much is needed here.
> 
> > ...snip...
> >>>> Section 3.1.4:
> >>> [BoB] I think that is elaborated in the existing term description
> >>> section 4.2 "Media Description". I can cross reference