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,

Thank you for the quick response. Please see below.

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

> Hi Spencer,
>
> Please see inline!
>
>
> Den 2015-12-03 kl. 06:48, skrev Spencer Dawkins:
>
>> 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?
>>
>
> 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
>    SSRCs comprising each participant will almost certainly see identical
>    reception quality, since they are co-located.
>
> 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?


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


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



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

Thanks,

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