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

[Magnus Westerlund <[e-mail]>]

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?

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

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

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