Subject: [avtext] Proposed RTP Taxonomy updates

From: Bo Burman <[email-masked]>
Date: Tue, 29 Apr 2014 13:26:55 +0000

Hi all,

Based on the AVTEXT session at IETF 88 & 89 and some mailing list discussions, I propose to make the following updates to RTP Taxonomy:

*         In 3.2.1 clearly define what RFC 6190 terms "SST" and "MST" means in Taxonomy terms and remove the current discussion on Single- and Multi-Stream.

*         Mention in 2.2.1 under Alternate usages that an "End Point" in Taxonomy terms is typically a single "host" (although "host" has no unique definition).

*         Change the term "Packet Stream" throughout the document, since it is arguably too generic:

o   "RTP Packet Stream" was suggested by Magnus W about a month ago and received some support. I think it is a bit long and unnecessarily redundant, since RTP already implies that it is a packet

o    "RTP Stream" could possibly be a sufficiently precise term; what do others think?

*         Re-structure the document such that Alternate usages (describing existing terms in Taxonomy wording) are separated out into their own sub-sections, making it possible to find them through the table of contents

o   I believe this could take care of Roni Even's request at IETF 88 for an overview table with existing terms, while avoiding the fact that the needed explanations will hardly fit in a table format.

*         Editorial:

o   Remove formal numberings of level 4 headings (change to body text or headings in body text format).

Comments are welcome!

Cheers,
Bo

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Apr 2014 06:48:48 -0700

With respect to SST/MST, as I recall, Alex's suggestion was to leave the RFC 6190 definition alone, but also define terminology for the single/multi-stream distinction. For example, it is possible to have multiple streams within a single session (SST-MS).

> On Apr 29, 2014, at 6:27, "Bo Burman" <[email-masked]> wrote:
> 
> Hi all,
>  
> ·         In 3.2.1 clearly define what RFC 6190 terms “SST” and “MST” means in Taxonomy terms and remove the current discussion on Single- and Multi-Stream.
> ·         Mention in 2.2.1 under Alternate usages that an “End Point” in Taxonomy terms is typically a single “host” (although “host” has no unique definition).
> ·         Change the term “Packet Stream” throughout the document, since it is arguably too generic:
> o   “RTP Packet Stream” was suggested by Magnus W about a month ago and received some support. I think it is a bit long and unnecessarily redundant, since RTP already implies that it is a packet
> o    “RTP Stream” could possibly be a sufficiently precise term; what do others think?
> ·         Re-structure the document such that Alternate usages (describing existing terms in Taxonomy wording) are separated out into their own sub-sections, making it possible to find them through the table of contents
> o   I believe this could take care of Roni Even’s request at IETF 88 for an overview table with existing terms, while avoiding the fact that the needed explanations will hardly fit in a table format.
> ·         Editorial:
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext
_______________________________________________
avtext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/avtext

---

From: Bo Burman <[email-masked]>
Date: Wed, 30 Apr 2014 11:47:10 +0000

With respect to leaving current SST/MST definition alone, I agree, but I think there was also agreement to describe them in Taxonomy terms, without re-defining anything.

In that, “MST” and “SST” without any distinction is unclear, but should according to IETF 89 discussions typically mean “MST-SS” and “SST-SS” , which should be described (with or without explicitly referring to any –SS and –MS distinctions).

Bernard and Alex, do I understand you correctly that you prefer to keep the –SS and –MS distinctions? I have no problem keeping it, and I am also open to alternative terminology describing the same thing. Do you have any proposals?

From: Bernard Aboba [mailto:[email-masked]]
Sent: den 29 april 2014 15:49
To: Bo Burman
Cc: [email-masked]; Alex Eleftheriadis
Subject: Re: [avtext] Proposed RTP Taxonomy updates

On Apr 29, 2014, at 6:27, "Bo Burman" <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

·         Editorial:

Comments are welcome!

Cheers,
Bo

_______________________________________________
avtext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/avtext

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Wed, 30 Apr 2014 18:12:51 +0000

Regarding the term of “RTP packet stream”, “packet stream”, or “RTP stream”,  I prefer “RTP stream” too.

On SST/MST, note that in the latest HEVC/H.265 payload draft, we are using “Single-Stream Transmission” and “Multi-Stream Transmission”. SST here is obviously within one RTP session, while MST herein can involve either a single or multiple RTP sessions. What is the importance of adding the suffix “-SS” or “-MS” herein in the term? Why it is not sufficient to just use SST/MST with the S in the middle mean “stream”?

BR, YK

From: avtext [mailto:[email-masked]] On Behalf Of Bo Burman
Sent: Wednesday, April 30, 2014 4:47 AM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [avtext] Proposed RTP Taxonomy updates

From: Bernard Aboba [mailto:[email-masked]]
Sent: den 29 april 2014 15:49
To: Bo Burman
Cc: [email-masked]<mailto:[email-masked]>; Alex Eleftheriadis
Subject: Re: [avtext] Proposed RTP Taxonomy updates

·         Editorial:

Comments are welcome!

Cheers,
Bo

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 30 Apr 2014 11:39:34 -0700

The problem is that the single/ multiple session and single/multiple stream dimensions are somewhat independent, and affect SFU design as well as client behavior.  In particular, SST-MS has now been widely implemented, so we cannot pretend it doesn't exist. Changing the meaning of the SST/MST abbreviations could potentially increase the already considerable confusion.

> On Apr 30, 2014, at 11:12 AM, "Wang, Ye-Kui" <[email-masked]> wrote:
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 01 May 2014 12:57:14 +1000

Hello Bo,

In London it was mentioned that there was a relationship with CLUE and 
XCON on how some of the taxonomy was used. In cl.2.2.3 of the draft 
there is a definition for the term "participant". In the XCON data model 
cl.4.6.5/[RFC6501] it uses the term "user" to describe the concept 
outlined in the draft definition. RFC4575 also uses the term "user" for 
this. IT might be good to mention this alternate term.

Regards, Christian

On 29/04/2014 11:26 PM, Bo Burman wrote:
>
> Hi all,
>
> Based on the AVTEXT session at IETF 88 & 89 and some mailing list 
> discussions, I propose to make the following updates to RTP Taxonomy:
>
> ·In 3.2.1 clearly define what RFC 6190 terms “SST” and “MST” means in 
> Taxonomy terms and remove the current discussion on Single- and 
> Multi-Stream.
>
> ·Mention in 2.2.1 under Alternate usages that an “End Point” in 
> Taxonomy terms is typically a single “host” (although “host” has no 
> unique definition).
>
> ·Change the term “Packet Stream” throughout the document, since it is 
> arguably too generic:
>
> o“RTP Packet Stream” was suggested by Magnus W about a month ago and 
> received some support. I think it is a bit long and unnecessarily 
> redundant, since RTP already implies that it is a packet
>
> o“RTP Stream” could possibly be a sufficiently precise term; what do 
> others think?
>
> ·Re-structure the document such that Alternate usages (describing 
> existing terms in Taxonomy wording) are separated out into their own 
> sub-sections, making it possible to find them through the table of 
> contents
>
> oI believe this could take care of Roni Even’s request at IETF 88 for 
> an overview table with existing terms, while avoiding the fact that 
> the needed explanations will hardly fit in a table format.
>
> ·Editorial:
>
> oRemove formal numberings of level 4 headings (change to body text or 
> headings in body text format).
>
> Comments are welcome!
>
> Cheers,
>
> Bo
>
>
>