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

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 02 Dec 2015 19:41:00 -0800

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.

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?

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Dec 2015 14:02:43 +0100

Hi Spencer,

Thanks for your comments. See inline

> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream/

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?

> 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

> I don't understand the subtlety of "more permanent" - is this

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  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 3 Dec 2015 08:04:35 -0600

Hi, Magnus,

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

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Dec 2015 15:22:39 +0100

Den 2015-12-03 kl. 15:04, skrev Spencer Dawkins at IETF:
> Hi, Magnus,
>
> On Thu, Dec 3, 2015 at 7:02 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi Spencer,
>
>         Please refer to
>         https://www.ietf.org/iesg/statement/discuss-criteria.html
>     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.
>
>     limitation to be in total bytes the initial packets may use, similar
>     to how the initial window is calculated?
>
>

I was simply asking, I tried to convey that I don't see any real issue 
here.

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

Sure, I have no problem adding "maximum" and the references to this note.

Cheers

Magnus Westerlund

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 3 Dec 2015 08:44:46 -0600

Hi, Magnus,

> I was simply asking, I tried to convey that I don't see any real issue

You were doing the right thing. I wasn't clear enough in my point.

> Sure, I have no problem adding "maximum" and the references to this note.

Thanks!

Spencer