Subject: Re: [avtext] Comments on transport terminology in draft-ietf-avtext-rtp-grouping-taxonomy-05

From: Bo Burman <[email-masked]>
Date: Mon, 2 Mar 2015 10:50:39 +0000

I wonder if your comments below at least partially relates to the fact that the text in the first part of 3.5 can be read as stating a design fact for "scalable media codecs", rather than describing a non-wanted and ambiguous definition in RFC 6190 that this draft would like to clarify and enhance?

Would it help if the text is changed to more clearly state what is the current situation, in what way it is ambiguous (maybe using words similar to yours below), and somehow makes it even more clear (text suggestion would be highly appreciated) that this draft suggests to use other terminology?

Further responses inline.

Cheers,
Bo

From: avtext [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: den 22 februari 2015 20:25
To: [email-masked]
Subject: Re: [avtext] Comments on transport terminology in draft-ietf-avtext-rtp-grouping-taxonomy-05

A few comments on Section 3.5:

3.5<https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-05#section-3.5>.  Single- and Multi-Session Transmission of Dependent Streams

   Scalable media coding formats such as, for example, H.264 based SVC

   [RFC6190<https://tools.ietf.org/html/rfc6190>] has two modes of operation:

   1.  In Single Session Transmission (SST), the SVC Media Encoder sends

       Encoded Streams (Section 2.1.7<https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-05#section-2.1.7>) and Dependent Streams

       (Section 2.1.8<https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-05#section-2.1.8>) as a single RTP Stream (Section 2.1.10<https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-05#section-2.1.10>) in a

       single RTP Session (Section 2.2.2<https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-05#section-2.2.2>), using the SVC RTP Payload

       format.

[BA] I do not believe this is accurate.  The term SST as defined in RFC 6190 appears to have different meanings within different sections of the document.  In sections relating to packetization, it appears to be synonymous with a single RTP Stream, since use of multiple streams requires support for the DON field.  However, in other sections (such in referring to SDP), the SST/MST terminology really does appear to refer to single versus multiple RTP sessions.

[BoB] I agree that use of SST/MST in RFC 6190 is unclear, no argument there. :)  I'm however not sure I understand what you believe to be inaccurate or how you would like to see the text changed? Is the text maybe unclear that both Encoded Streams and Dependent Streams are sent within one and the same RTP Stream for SST? That is at least what is meant, and I can amend the text to say that. I also see no problem to add something similar to your text above, describing in what sense SST is unclear in RFC 6190.

   2.  In Multi-Session Transmission (MST), the SVC Media Encoder sends

       Encoded Streams and Dependent Streams distributed across multiple

       RTP Streams in one or more RTP Sessions.

[BA] The meaning of MST in RFC 6190 is not really that clear. If you are referring to use of the DON field, this is needed whenever multiple RTP streams are used regardless of whether we are talking about multiple RTP sessions or not.

[BoB] Yes. It was already suggested to use "two or more" instead of "multiple" above, which should be clearer and make the sentence more correct. Also here, I see no problems being more explicit in what is unclear with MST.

   SST denotes one RTP Stream (SSRC) per Media Source in a single RTP

   Session.  MST denotes one or more RTP Streams (SSRC) per Media Source

   in each of multiple RTP Sessions.  The above is not unambiguously

   specified in the SVC payload format text [RFC6190<https://tools.ietf.org/html/rfc6190>], but it is what

   existing deployments of that RFC have implemented.

[BA] The use of multiple RTP streams within a single RTP session is in fact implemented - this is what was implemented in Lync 2013.

[BoB] Then the text should be changed accordingly! Maybe we should just refrain from talking about what "existing deployments" do or don't do, and remove this paragraph entirely, as text on the ambiguities with SST/MST should, with the suggested changes, now be addressed directly in items 1 and 2?

   The use of the term "RTP Session" in the SST/MST definition is

   somewhat misleading, since a single RTP Session can contain multiple

   RTP Streams.

[BA] My advice would be to point out the ambiguities in RFC 6190 SST/MST terminology, while not attempting to fix them retroactively.  Overall, it is more productive

to focus this document on the new  SRST/MRST/MRMT terminology.

[BoB] Fully agree! Would the changes suggested above address your concerns of not fixing SST/MST, but rather describe what is unclear with SST/MST, and focus on the new terminology?

   Also, it is sometimes useful to make a distinction

   between using a single Media Transport or multiple separate Media

   Transports when (in both cases) using multiple RTP Streams to carry

   Encoded Streams and Dependent Streams for a Media Source.  Therefore,

   herein the following new terminology is defined:

   SRST:  Single RTP Stream on a Single Media Transport

   MRST:  Multiple RTP Streams on a Single Media Transport

   MRMT:  Multiple RTP Streams on Multiple Media Transports

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 2 Mar 2015 14:26:44 +0100

Hi,

Having reviewed the text in 3.5 and 3.8 I think it is very reasonable to
go the proposed and focusing on defining the terms to use in the future
for these configurations. I must however note that 3.8 has significant
overlap, and thus I think one should combine 3.5 and 3.8 into a Scalable
Coding Transport, and have the definition and the example figure etc. in
one section.

Views on this?

/Magnus

On 2015-03-02 11:50, Bo Burman wrote:
> I wonder if your comments below at least partially relates to the fact
> that the text in the first part of 3.5 can be read as stating a design
> fact for “scalable media codecs”, rather than describing a non-wanted
> and ambiguous definition in RFC 6190 that this draft would like to
> clarify and enhance?
> 
>  
> 
> Would it help if the text is changed to more clearly state what is the
> current situation, in what way it is ambiguous (maybe using words
> similar to yours below), and somehow makes it even more clear (text
> suggestion would be highly appreciated) that this draft suggests to use
> other terminology?
> 
>  
> 
> *From:*avtext [mailto:[email-masked]] *On Behalf Of *Bernard Aboba
> *Sent:* den 22 februari 2015 20:25
> *To:* [email-masked]
> *Subject:* Re: [avtext] Comments on transport terminology in
> draft-ietf-avtext-rtp-grouping-taxonomy-05
> 
>  
> 
>       3.5
>       <https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-05#section-3.5>. 
>       Single- and Multi-Session Transmission of Dependent Streams
> 
>  
> 
>  
> 
>    [RFC6190 <https://tools.ietf.org/html/rfc6190>] has two modes of operation:
> 
>  
> 
>        Encoded Streams (Section 2.1.7 <https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-05#section-2.1.7>) and Dependent Streams
> 
>        (Section 2.1.8 <https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-05#section-2.1.8>) as a single RTP Stream (Section 2.1.10 <https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-05#section-2.1.10>) in a
> 
>        single RTP Session (Section 2.2.2 <https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-05#section-2.2.2>), using the SVC RTP Payload
> 
>        format.
> 
>  
> 
> */[BoB] I agree that use of SST/MST in RFC 6190 is unclear, no argument there. :)  I’m however not sure I understand what you believe to be inaccurate or how you would like to see the text changed? Is the text maybe unclear that both Encoded Streams and Dependent Streams are sent within one and the same RTP Stream for SST? That is at least what is meant, and I can amend the text to say that. I also see no problem to add something similar to your text above, describing in what sense SST is unclear in RFC 6190./*
> 
>  
> 
>  
> 
> */[BoB] Yes. It was already suggested to use “two or more” instead of “multiple” above, which should be clearer and make the sentence more correct. Also here, I see no problems being more explicit in what is unclear with MST./*
> 
>   
> 
>  
> 
>    specified in the SVC payload format text [RFC6190 <https://tools.ietf.org/html/rfc6190>], but it is what
> 
> */[BoB] Then the text should be changed accordingly! Maybe we should just refrain from talking about what “existing deployments” do or don’t do, and remove this paragraph entirely, as text on the ambiguities with SST/MST should, with the suggested changes, now be addressed directly in items 1 and 2?/*
> 
> */ /*
> 
>  
> 
> */[BoB] Fully agree! Would the changes suggested above address your concerns of not fixing SST/MST, but rather describe what is unclear with SST/MST, and focus on the new terminology?/*
> 
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext
> 

-- 

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

---

From: Bo Burman <[email-masked]>
Date: Tue, 3 Mar 2015 12:28:35 +0000

I can agree that 3.5 and 3.8 have significant overlap and would probably benefit from a merge (into a new 3.7, then).

I don't think "Scalable Coding Transport" is a good heading in a section describing "Concepts of Inter-Relations". Would keeping "Layered Multi-Stream", changing it to "Scalable Encoding", or something else (what?) be a good heading for that new 3.7?

When thinking about it, I wonder if that merged new section should preferably refrain as much as possible from mentioning the unclear MST/SST terminology, concentrating on the new terms? The type of descriptive text on MST/SST suggested by Bernard should perhaps rather be included in sub-section(s) in section 4, describing them as existing terms, and probably refer back to the new 3.7?

Cheers,
Bo

> -----Original Message-----
> From: Magnus Westerlund
> Sent: den 2 mars 2015 14:27
> To: Bo Burman; Bernard Aboba; [email-masked]
> Having reviewed the text in 3.5 and 3.8 I think it is very reasonable to go the proposed and focusing on defining the terms
> to use in the future for these configurations. I must however note that 3.8 has significant overlap, and thus I think one
> should combine 3.5 and 3.8 into a Scalable Coding Transport, and have the definition and the example figure etc. in one
> section.
> 
> Views on this?
> 
> /Magnus
> 
> 
> > fact for "scalable media codecs", rather than describing a non-wanted
> > suggestion would be highly appreciated) that this draft suggests to
> > use other terminology?
> >
> >
> >
> >        Encoded Streams (Section 2.1.7
> > <https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-0
> > 5#section-2.1.7>) and Dependent Streams
> >
> >        (Section 2.1.8
> > <https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-0
> > 5#section-2.1.8>) as a single RTP Stream (Section 2.1.10
> > <https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-0
> > 5#section-2.1.10>) in a
> >
> >        single RTP Session (Section 2.2.2
> > <https://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-0
> > 5#section-2.2.2>), using the SVC RTP Payload
> >
> >        format.
> >
> >
> >
> > [BA] I do not believe this is accurate.  The term SST as defined in RFC 6190 appears to have different meanings within
> different sections of the document.  In sections relating to packetization, it appears to be synonymous with a single RTP
> Stream, since use of multiple streams requires support for the DON field.  However, in other sections (such in referring to
> SDP), the SST/MST terminology really does appear to refer to single versus multiple RTP sessions.
> >
> > */[BoB] I agree that use of SST/MST in RFC 6190 is unclear, no
> > argument there. :)  I'm however not sure I understand what you believe
> > to be inaccurate or how you would like to see the text changed? Is the
> > text maybe unclear that both Encoded Streams and Dependent Streams are
> > sent within one and the same RTP Stream for SST? That is at least what
> > is meant, and I can amend the text to say that. I also see no problem
> > to add something similar to your text above, describing in what sense
> > SST is unclear in RFC 6190./*
> >
> >
> >
> >
> >
> > [BA] The meaning of MST in RFC 6190 is not really that clear. If you are referring to use of the DON field, this is needed
> whenever multiple RTP streams are used regardless of whether we are talking about multiple RTP sessions or not.
> >
> > */[BoB] Yes. It was already suggested to use "two or more" instead of
> > "multiple" above, which should be clearer and make the sentence more
> > correct. Also here, I see no problems being more explicit in what is
> > unclear with MST./*
> >
> >
> >
> >
> >
> >    specified in the SVC payload format text [RFC6190
> > <https://tools.ietf.org/html/rfc6190>], but it is what
> >
> > */[BoB] Then the text should be changed accordingly! Maybe we should
> > just refrain from talking about what "existing deployments" do or
> > don't do, and remove this paragraph entirely, as text on the
> > ambiguities with SST/MST should, with the suggested changes, now be
> > addressed directly in items 1 and 2?/*
> >
> > */ /*
> >
> >
> >
> > [BA] My advice would be to point out the ambiguities in RFC 6190
> > SST/MST terminology, while not attempting to fix them retroactively.
> > Overall, it is more productive
> >
> > */[BoB] Fully agree! Would the changes suggested above address your
> > concerns of not fixing SST/MST, but rather describe what is unclear
> > with SST/MST, and focus on the new terminology?/*
> >
> >

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 3 Mar 2015 09:52:44 -0500

Focusing on the new terms seems like a better idea to me. 

> On Mar 3, 2015, at 7:28 AM, Bo Burman <[email-masked]> wrote:
>