Subject: Re: [avtext] Proposed RTP Taxonomy updates

From: Alex Eleftheriadis <[email-masked]>
Date: Thu, 1 May 2014 09:44:24 +0000

I agree with Bernard. There is now both SST-MS and SST-SS widely deployed but, more importantly, the concepts are truly distinct. So we should not "overload" SST to always mean one or the other.

W.r.t. the HEVC payload spec, I would argue that redefining it there to mean stream rather than session, as it does in the H.264 spec, should be seriously reconsidered.

As someone who, for many years, has tried to explain these architectures to several people, a lot of them technically very very knowledgeable, I have found the lack of appropriate commonly accepted terminology a serious impediment. Now that these architectures are investigated very extensively,  we have a great opportunity to fix that and do it the right way. Redefining acronyms, and particularly in the same series of specifications, is imho going in the exactly opposite direction.

Maybe we can use something like "configuration": Single Stream Configuration (SSC) and Multi-Stream Configuration (MSC). They describe how the layers are configured for transmission, not how they are transmitted. The transmission part comes next, and uses the SST and MST acronyms.  That would simplify potential changes to all drafts, and avoid confusion.

--Alex [with apologies for not always closely following the thread]

On Apr 30, 2014, at 9:39 PM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:

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]<mailto:[email-masked]>> wrote:

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]<mailto:[email-masked]>
Subject: Re: [avtext] Proposed RTP Taxonomy updates

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]<mailto:[email-masked]>; Alex Eleftheriadis
Subject: Re: [avtext] Proposed RTP Taxonomy updates

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]<mailto:[email-masked]>> 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
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

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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 1 May 2014 05:39:56 -0700

> 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…

I do not believe that MST-SS makes sense - it would imply use of the same SSRC in multiple sessions. Since SSRC collisions are detected within a session, the SSRC could change in one session, and not another. So MST-MS makes more sense.

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Sat, 3 May 2014 00:23:09 +0000

[Posting it to payload reflector as well].

I am fine with Alex's suggestion on Single Stream Configuration (SSC) and Multi-Stream Configuration (MSC) to replace SST/MST in the HEVC payload format. Does anyone else has an opinion here?

@Bernard: Note that changing of "S" the middle of "SST" and "MST" from "session" to "stream" in the HEVC payload draft was a result from one of your suggestions.

@Bernard and Alex: It is just editorial, I don't understand why it is relevant to mention whether something has been implemented or not - you implement techniques not editorial terms - unless you meant "implemented or deployed in specifications".

Anyway, I hope you guys can converge on the terms soon.

BR, YK

From: Alex Eleftheriadis [mailto:[email-masked]]
Sent: Thursday, May 01, 2014 2:44 AM
To: Bernard Aboba
Cc: Wang, Ye-Kui; Bo Burman; [email-masked]
Subject: Re: [avtext] Proposed RTP Taxonomy updates

On Apr 30, 2014, at 11:12 AM, "Wang, Ye-Kui" <[email-masked]<mailto:[email-masked]>> wrote:
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

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?

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: Bo Burman <[email-masked]>
Date: Mon, 5 May 2014 07:23:18 +0000

I think we may have different interpretations of MST-SS? To me, MST-SS is multiple RTP Sessions, each with a single stream. I don’t see any requirement that those streams necessarily use the same SSRC value. Why do you make that assumption?

So to clarify even further, when suggesting MST-MS, do you mean that the current main use of “MST” is multiple RTP Sessions, each with multiple streams using different SSRC?

From: Bernard Aboba [mailto:[email-masked]]
Sent: den 1 maj 2014 14:40
To: Bo Burman
Cc: [email-masked]; Alex Eleftheriadis
Subject: Re: [avtext] Proposed RTP Taxonomy updates

On Apr 30, 2014, at 4:47, "Bo Burman" <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 5 May 2014 10:16:05 +0200

Hi,

The definitions of the MST-SS that exist is based on this matrix from
the current taxonomy draft:

   +-----------------------+--------------------+----------------------+
   |                       | Single RTP Session | Multiple RTP         |
   |                       |                    | Sessions             |
   +-----------------------+--------------------+----------------------+
   | Single Packet Stream  | SST-SS             | MST-SS               |
   | Multiple Packet       | SST-MS             | MST-MS               |
   | Streams               |                    |                      |
   +-----------------------+--------------------+----------------------+

Which means that MST-SS is a single packet stream per RTP session, but
that multiple RTP sessions are used to spread the encoded stream and is
dependent streams over.

The intention was not to restrict the SSRC in these different RTP
sessions, rather if one is supporting this mode of operation, I think
the solution MUST be capable of handling different SSRCs in the various
RTP sessions. If not one ends up with some inter session dependencies,
especially how SSRC collision effects the various sessions.

I will note that if one redefines MST to means Multiple Stream
Transmission, then SST-MS must also be changed.

Cheers

Magnus

On 2014-05-05 09:23, Bo Burman wrote:
> I think we may have different interpretations of MST-SS? To me, MST-SS
> is multiple RTP Sessions, each with a single stream. I don’t see any
> requirement that those streams necessarily use the same SSRC value. Why
> do you make that assumption?
> 
>  
> 
> So to clarify even further, when suggesting MST-MS, do you mean that the
> current main use of “MST” is multiple RTP Sessions, each with multiple
> streams using different SSRC?
> 
>  
> 
> *From:*Bernard Aboba [mailto:[email-masked]]
> *Sent:* den 1 maj 2014 14:40
> *To:* Bo Burman
> *Cc:* [email-masked]; Alex Eleftheriadis
> *Subject:* Re: [avtext] Proposed RTP Taxonomy updates
> 
>  
> 
>     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).
> 
>  
> 
> I do not believe that MST-SS makes sense - it would imply use of the
> same SSRC in multiple sessions. Since SSRC collisions are detected
> within a session, the SSRC could change in one session, and not another.
> So MST-MS makes more sense. 
> 
> 
> 
> [email-masked]

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------