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

[Magnus Westerlund <[e-mail]>]

Den 2015-12-03 kl. 14:52, skrev Spencer Dawkins at IETF:
> Hi, Magnus,
>
> 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
> <[e-mail] <mailto:[e-mail]>>
> 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.

>
> But please keep reading. :-)
>
>
>
>
>         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.
>
>
>     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.

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.

>
>
>
>
>
>         ----------------------------------------------------------------------
>         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?
>
>
>     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.
>
>
> 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

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------