Subject: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-multi-stream-optimisation-09: (with DISCUSS and COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 02 Dec 2015 21:48:35 -0800

Spencer Dawkins has entered the following ballot position for
draft-ietf-avtcore-rtp-multi-stream-optimisation-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream-optimisation/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm lost on something here, so I'd like to discuss it briefly so that I
understand what I'm looking at. I'm not expecting this to be hard to
resolve.

In this text

   However, the three
   SSRCs comprising each participant will almost certainly see identical
   reception quality, since they are co-located.
   
it sounds like you're describing a heuristic ("will almost certainly
see", so if you use a reporting group, the results will be close enough).

In other places in the document, like

   Since they are co-located, every
   SSRC in the RTCP reporting group will have an identical view of the
   network conditions, and see the same lost packets, jitter, etc.  
   
it sounds like you're saying they'll always have an identical view ("will
see", with no qualification). 

Which is it?

As a comment, but on exactly the second text so I'll include it here, is
"see the same lost packets" telling me that more than one SSRC is sending
"the same lost packets"? If this was "see (roughly) the same loss rate",
I wouldn't be surprised, but I'm confused here.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This text 

   An RTP endpoint will have one or more synchronisation sources (SSRCs)
   that send media streams.  It will have at least one SSRC for each
   media stream it sends, and might use multiple SSRCs when using media
   scalability features [RFC6190], forward error correction, RTP
   retransmission [RFC4588], or similar mechanisms.  An endpoint that is
   not sending any media streams, will have at least one SSRC to use for
   reporting and any feedback messages.  

was somewhat confusing for me. It's saying that an RTP endpoint will
always have one or more SSRCs that send media streams, except that it
might not send media streams, but then it still has at least one SSRC
that doesn't send a media stream. Could you think about whether this
could be clearer?

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Dec 2015 09:46:33 +0100

Hi Spencer,

Please see inline!

> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream-optimisation/

It is the later, if you to the next paragraph after the second quote 
above (First in Section 3.1), you can read the following:

    A group of co-located SSRCs that see identical network conditions can
    form an RTCP reporting group.  If reporting groups are in use, an RTP
    endpoint with multiple SSRCs MAY put those SSRCs into a reporting
    group if their view of the network is identical; i.e., if they report
    on traffic received at the same interface of an RTP endpoint.  SSRCs
    with different views of the network MUST NOT be put into the same
    reporting group.

It is in fact a requirement to have the same view of the network to use 
this extension.

The introduction section the message is:

In most cases the endpoints SSRCs will be co-located (there exist some 
few exception to this with distributed end-points), if that is the case, 
then one would be able to suppress a lot of reporting.

I can see your confusion, I think the easiest way of fixing this is to 
change the introduction sentence slightly to be clearer on that this is 
a conditional statement:

Section 1.
OLD:

However, the three

NEW:

However, the three SSRCs comprising each participant are commonly 
co-located such that they see identical reception quality.

Does the above address the issue?

> I wouldn't be surprised, but I'm confused here.

No, this is referring to incoming RTP streams, where an endpoint detects 
a lost packet based on gaps in the sequence number series of the 
received packets. These are in core RTP (RFC3550) reported in 
Sender/Receiver Reports by each of the SSRCs that the local endpoint have.

I see that we actually failed to align this section correctly with the 
taxonomy in RFC7656. If one rewrites it using the taxonomy of the RFC it 
becomes:

    An RTP endpoint will have one or more synchronisation sources (SSRCs)
    that send RTP streams.  It will have at least one SSRC for each
    media source it sends, and might use multiple SSRCs when using media
    scalability features [RFC6190], forward error correction, RTP
    retransmission [RFC4588], or similar mechanisms.  An endpoint that is
    not sending any media sources, will have at least one SSRC to use for
    reporting and any feedback messages.

And I note that we should actually address all occurrences of "media 
stream" in the introduction, the only place that combination of words 
exist.

But the point of the first paragraph, plus what you quote in this 
comment is that there can be multiple SSRCs in an RTP session per 
endpoint due to multiple media sources, or that one uses multiple RTP 
streams (SSRCs) per media source. That added with the knowledge that a 
particular RTP stream, and even media source can be temporarily paused 
for various reasons results in the above text.

Cheers

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: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 3 Dec 2015 07:52:36 -0600

Hi, Magnus,

Thank you for the quick response. Please see below.

On Thu, Dec 3, 2015 at 2:46 AM, Magnus Westerlund <
[email-masked]> wrote:

> It is the later, if you to the next paragraph after the second quote above
> (First in Section 3.1), you can read the following:
>
> In most cases the endpoints SSRCs will be co-located (there exist some few
> exception to this with distributed end-points), if that is the case, then
> one would be able to suppress a lot of reporting.
>
> change the introduction sentence slightly to be clearer on that this is a
> conditional statement:
>
> Section 1.
> OLD:
>
> However, the three

That's enough for me to clear. If the answer was that that they were almost
always seeing identical reception quality, that would drop us down the
rabbit hole of "how do you know whether they're seeing identical reception
quality, what can go wrong if you are using this mechanism and they aren't
seeing identical reception quality", etc. So, that's the right answer.

But please keep reading. :-)

> No, this is referring to incoming RTP streams, where an endpoint detects a
> lost packet based on gaps in the sequence number series of the received
> packets. These are in core RTP (RFC3550) reported in Sender/Receiver
> Reports by each of the SSRCs that the local endpoint have.

I still don't understand whether they're seeing the same lost packet in
multiple SSRCs. If they are, that means I don't understand RTP/RTCP as well
as I would like to. If they're not, the text isn't quite right.

> stream" in the introduction, the only place that combination of words exist.
>
> But the point of the first paragraph, plus what you quote in this comment
> is that there can be multiple SSRCs in an RTP session per endpoint due to
> multiple media sources, or that one uses multiple RTP streams (SSRCs) per
> media source. That added with the knowledge that a particular RTP stream,
> and even media source can be temporarily paused for various reasons results
> in the above text.

Right. What I'm saying is confusing, is that the text says an RTP endpoint
will have one or more SSRCs that send RTP streams, full stop. It then goes
on to say that some RTP endpoints DON'T have any SSRCs that send RTP
streams, they're only sending reporting and feedback messages - but they're
still RTP endpoints.

Do you see why I'm lost?

Thanks,

Spencer

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Dec 2015 15:19:02 +0100

> Thank you for the quick response. Please see below.

Removing the parts that are "solved"

>
> On Thu, Dec 3, 2015 at 2:46 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> That's enough for me to clear. If the answer was that that they were
> almost always seeing identical reception quality, that would drop us
> down the rabbit hole of "how do you know whether they're seeing
> identical reception quality, what can go wrong if you are using this
> mechanism and they aren't seeing identical reception quality", etc. So,
> that's the right answer.

Will introduce the change at suitable point.

>     No, this is referring to incoming RTP streams, where an endpoint
>     detects a lost packet based on gaps in the sequence number series of
>     the received packets. These are in core RTP (RFC3550) reported in
> multiple SSRCs. If they are, that means I don't understand RTP/RTCP as
> well as I would like to. If they're not, the text isn't quite right.

I will assume that you don't understand RTP/RTCP well enough and try to 
explain the above question as well as possible.

So an RTP implementation, "the stack" listens on one or more 
ports/connections (usually UDP) for incoming RTP/RTCP traffic. This 
local instance will have SSRCs based on its need. An RTP receiver only, 
would still have one SSRC, simply to have an identity towards the 
endpoints transmitting RTP stream. This SSRC will only be used in RTCP 
packets, but to identify from who reporting and feedback messages are from.

If an local endpoint have the need to transmit multiple RTP streams then 
it will have multiple SSRCs. However, as the RTCP reporting is defined, 
all SSRC needs to send regular Sender/Receiver Report (SR/RR) packets 
combined with SDES CNAME information to basically re-assert that I am 
still here. So the stack when generating the RTCP SR/RR reporting 
blocks, they will take the information from a local database that is 
updated with information for each incoming RTP packet. This is what 
causes us to state all SSRCs that send RTCP from the same stack instance 
in the same endpoint using a particular interface will thus have an 
identical view on a packet loss. Simply because it is the stack instance 
that seen the lost, and it has multiple identities towards other session 
participants.

>     I see that we actually failed to align this section correctly with
>     the taxonomy in RFC7656. If one rewrites it using the taxonomy of
>     the RFC it becomes:
>
>     endpoint due to multiple media sources, or that one uses multiple
>     RTP streams (SSRCs) per media source. That added with the knowledge
>     that a particular RTP stream, and even media source can be
>     temporarily paused for various reasons results in the above text.
>
>
> Right. What I'm saying is confusing, is that the text says an RTP
> endpoint will have one or more SSRCs that send RTP streams, full stop.
> It then goes on to say that some RTP endpoints DON'T have any SSRCs that
> send RTP streams, they're only sending reporting and feedback messages -
> but they're still RTP endpoints.
>
> Do you see why I'm lost?
>

Okay, so it is simply a lack of noting the exception case in the initial 
sentence: "An RTP endpoint will have one or more synchronisation sources 
(SSRCs) that send RTP streams.". Replacing "will" with "can" should 
resolve it.

I also note that it might be better to use "RTP stream instead of "Media 
Source" in

"An endpoint that is not sending any media sources, will have at least
  one SSRC to use for reporting and any feedback messages."

I think the conclusion is that the introduction section do need a little 
bit of editing before being approved. I would suggest "Reviesed ID 
needed" and run an edited version past you and the WG.

Cheers

Magnus Westerlund

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 3 Dec 2015 08:34:11 -0600

Hi, Magnus,

> explain the above question as well as possible.

That's usually a safe assumption ;-)

> ports/connections (usually UDP) for incoming RTP/RTCP traffic. This local
> instance will have SSRCs based on its need. An RTP receiver only, would
> still have one SSRC, simply to have an identity towards the endpoints
> transmitting RTP stream. This SSRC will only be used in RTCP packets, but
> to identify from who reporting and feedback messages are from.
>
> it will have multiple SSRCs. However, as the RTCP reporting is defined, all
> SSRC needs to send regular Sender/Receiver Report (SR/RR) packets combined
> with SDES CNAME information to basically re-assert that I am still here. So
> the stack when generating the RTCP SR/RR reporting blocks, they will take
> the information from a local database that is updated with information for
> each incoming RTP packet. This is what causes us to state all SSRCs that
> send RTCP from the same stack instance in the same endpoint using a
> particular interface will thus have an identical view on a packet loss.
> Simply because it is the stack instance that seen the lost, and it has
> multiple identities towards other session participants.
>
>
This was helpful. Thanks!

> (SSRCs) that send RTP streams.". Replacing "will" with "can" should resolve
> it.

Exactly.

>  one SSRC to use for reporting and any feedback messages."

That helps me, for sure.

> bit of editing before being approved. I would suggest "Reviesed ID needed"
> and run an edited version past you and the WG.

Do the right thing, of course.

Spencer