Re: [AVTCORE] Spencer Dawkins' Yes on draft-ietf-avtcore-rtp-multi-stream-10: (with COMMENT)

[Magnus Westerlund <[e-mail]>]

Hi Spencer,

Thanks for your comments. See inline

Den 2015-12-03 kl. 04:41, skrev Spencer Dawkins:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-avtcore-rtp-multi-stream-10: Yes
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for doing this work.
>
> I have a small number of comments you might consider.
>
> In this text:
>
>        Note: The above is chosen to match the TCP initial window of 4
>        packets, not the larger TCP initial windows for which there is an
>        ongoing experiment.  The reason for this is a desire to be
>        conservative, since an RTP endpoint will also in many cases start
>        sending RTP data packets at the same time as these initial RTCP
>        packets are sent.
>
> Not to be pedantic, but it would be more correct to say "TCP maximum
> initial window of 4 packets". RFC 3390 describes this in TCP-speak as
>
>     Equivalently, the upper bound for the initial window size is based on
>     the MSS, as follows:
>
>         If (MSS <= 1095 bytes)
>             then win <= 4 * MSS;
>         If (1095 bytes < MSS < 2190 bytes)
>             then win <= 4380;
>         If (2190 bytes <= MSS)
>             then win <= 2 * MSS;
>
> If you end up making changes to this text, providing RFC 3390 as the
> reference for 4 and RFC 6928 for the experiment would make the reader's
> job easier.

Yes, we should include the references. So, there are no hard limits on 
how big the RTCP compound packets can be, but they do need to be within 
MTU. So for IPv6's 1280 and the Ethernet standard MTU I don't see any 
issues that this would result in slightly more data than what TCP would 
send. The difference would be significant when we get to 4k or 9K MTUs. 
However, I would expect environments where you get this to work, they 
will not have an issue with sending 4*MTU in data amount.

Do any on IESG foresee an issue, such that we should redefine the 
limitation to be in total bytes the initial packets may use, similar to 
how the initial window is calculated?

>
> In this text:
>
>     The above algorithm has been shown in simulations to maintain the
>     inter-RTCP packet transmission time distribution for each SSRC, and
>     to consume the same amount of bandwidth as non-aggregated RTCP
>     packets.
>
> is there a reference you could provide for the simulations?

Yes, to presentations in the IETF Proceedings.

http://www.ietf.org/proceedings/88/slides/slides-88-avtcore-0.pdf
http://www.ietf.org/proceedings/89/slides/slides-89-avtcore-1.pdf
https://www.ietf.org/proceedings/92/slides/slides-92-avtcore-0.pdf

>
> In this text:
>
>     The finality of sending RTCP BYE, means that endpoints needs to
>     consider if the ceasing of transmission of an RTP stream is temporary
>     or more permanent.
>
> I don't understand the subtlety of "more permanent" - is this
> "permanent"?
>

I guess if using "permanent" we should remove more. But, it comes down 
to if an end-point believes it has no further use for the SSRC or not. 
In most context an endpoint can always create a new SSRC if it realizes 
that it shouldn't have terminated the use of a SSRC.

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