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

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

Hi, Magnus,

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

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


Oh, heavens, don't do that!

My point was only that that the standard TCP initial window isn't always 4
segments, and I was hoping to make that clearer by saying "maximum initial
window".

People spilled enough blood on the 2, or 3, or 4 discussion leading up to
RFC 3390, that I'd like to avoid confusing new transport folk now.

Spencer


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