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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Magnus,

On Thu, Dec 3, 2015 at 8:19 AM, Magnus Westerlund <
[e-mail]> wrote:

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


That's usually a safe assumption ;-)


> 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.
>
>
This was helpful. Thanks!


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


Exactly.


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


That helps me, for sure.


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


Do the right thing, of course.

Spencer


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