Subject: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-circuit-breakers-14: (with DISCUSS)

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 19 Apr 2016 18:20:41 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-avtcore-rtp-circuit-breakers-14: 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-circuit-breakers/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I really like this specification, and have two questions I'd like to
understand before balloting YES ...

I'm looking at this text:

4.5.  Ceasing Transmission

   What it means to cease transmission depends on the application.  The
   intention is that the application will stop sending RTP data packets
   to a particular destination 3-tuple (transport protocol, destination
   port, IP address), until the user makes an explicit attempt to
   restart the call.  It is important that a human user is involved in
   the decision to try to restart the call, since that user will
   eventually give up if the calls repeatedly trigger the circuit
   breaker.  This will help avoid problems with automatic redial systems
   from congesting the network.  Accordingly, RTP flows halted by the
   circuit breaker SHOULD NOT be restarted automatically unless the
                   ^^^^^^^^^^
   sender has received information that the congestion has dissipated,
   or can reasonably be expected to have dissipated. 
   
and trying to understand why this is not MUST NOT. I'm trying to
reconcile this with the RFC 2119 definition of SHOULD NOT, which is

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.
   
Could you help me understand when automatic restarts might be "acceptable
or even useful"?

Reading on, I'm wondering if this text is anticipating 

   It is recognised that the RTP implementation in some systems might
   not be able to determine if a call set-up request was initiated by a
   human user, or automatically by some scripted higher-level component
   of the system.
   
but definitely want to understand what you're thinking here.

I have a similar question about this text 

   ECN-CE marked packets SHOULD be treated as if it were lost for the
   purposes of congestion control, when determining the optimal media
   sending rate for an RTP flow.  If an RTP sender has negotiated ECN
   support for an RTP session, and has successfully initiated ECN use on
   the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD
                                                                  ^^^^^^
   be treated as if they were lost when calculating if the congestion-
   based RTP circuit breaker (Section 4.3) has been met.  

Could you help me understand why an implementation wouldn't do this?

---

From: Colin Perkins <[email-masked]>
Date: Tue, 26 Apr 2016 15:43:01 +0100

Spencer,

> On 20 Apr 2016, at 02:20, Spencer Dawkins <[email-masked]> wrote:
> 
> Could you help me understand when automatic restarts might be “acceptable or even useful”?

As stated, automatic restarts might be acceptable or even useful if the sender receives information that the congestion has dissipated, or can reasonably be expected to have dissipated. This is why it says “SHOULD NOT … unless <reasons>” rather than “MUST NOT”. 

> Could you help me understand why an implementation wouldn't do this?

Because there are a small number of paths that misbehave when ECN marked packet are sent. I wanted to allow leeway for an end-point to not respond to ECN-CE marks on paths that spuriously mark packets, so falling back to the behaving as-if ECN was not used. I don’t believe this is harmful to the network, since the result will be the same as achieved by a non-ECN capable transport.

-- 
Colin Perkins
https://csperkins.org/

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 26 Apr 2016 17:08:12 -0500

Hi, Colin,

On Tue, Apr 26, 2016 at 9:43 AM, Colin Perkins <[email-masked]> wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> As stated, automatic restarts might be acceptable or even useful if the
> sender receives information that the congestion has dissipated, or can
> reasonably be expected to have dissipated. This is why it says “SHOULD NOT
> … unless <reasons>” rather than “MUST NOT”.

Hi, Colin,

On this one, I was getting tripped up on "or can be reasonably expected to
have dissipated" for an automatic restart, but if this means that an
implementer has thought about what has to happen before an implementation
does a restart with no user involvement, I can see that.

I was getting tied up with the subsequent text, but perhaps I shouldn't
have been.

Thanks for the help on that one.

> Because there are a small number of paths that misbehave when ECN marked
> packet are sent. I wanted to allow leeway for an end-point to not respond
> to ECN-CE marks on paths that spuriously mark packets, so falling back to
> the behaving as-if ECN was not used. I don’t believe this is harmful to the
> network, since the result will be the same as achieved by a non-ECN capable
> transport.

So, the scenario you're thinking of, is that you and I negotiated ECN
support for a session, I started marking packets, and a path started
marking packets with ECN-CE whether congestion was being encountered or
not, and I realize that's happening (by some logic not specified), so I
can't trust ECN-CE.

Do I have that right? Assuming I'm close ...

So, since I can't trust ECN-CE, I keep sending as if I wasn't getting
ECN-CE, and either that works (so, I did the right thing), or I manage to
cause enough congestion that it shows up in RTCP reports (so, I did the
wrong thing before, but I'll react to the less problematic RTCP reports and
do the right thing now, and that won't be any worse than what would have
happened if we hadn't been able to negotiate ECN support in the first
place).

Do I have that right? Again, assuming that I'm at least close ...

I think what you're doing is "safe enough" that this isn't Discuss-worthy,
so I'll clear, but I wish the explanation of what's going on here was more
explicit. If you want to try to make that happen, I'm happy to chat further.

Thanks,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 26 Apr 2016 17:28:05 -0500

Hi, Colin,

On Tue, Apr 26, 2016 at 5:13 PM, Colin Perkins <[email-masked]> wrote:

> Hi,
>
> > On 26 Apr 2016, at 23:08, Spencer Dawkins at IETF <
> [email-masked]> wrote:
> >
> > Hi, Colin,
> >
> Thanks. Happy to clarify, if you have suggestions.

I think the point that had my shoelaces tied together was the incongruity
of an RTP implementation itself with expectations.

If you can come up with text that says something like "or can be reasonably
expected to have dissipated, based on the amount of time that has elapsed
since the circuit breaker has tripped", or whatever else you're thinking
of, that would have helped me.

(I'm assuming that the only thing an implementation has to work with when
it hasn't received information that congestion has dissipated, would be the
passage of time, but you'd know better what would be reasonable here)

> > Do I have that right? Assuming I’m close ...
>
> Yes, that’s one possible scenario. I can’t find it now, but I also seem to
> recall Apple reporting on strange experiences with ECN at a recent IETF.

Yum.

> > Do I have that right? Again, assuming that I’m at least close ...
>
> Yup.
>
> > explicit. If you want to try to make that happen, I'm happy to chat
> further
>
> Happy to revise, if you think it would help. It’s better to make this
> clear, if we can.

So, at the risk of making an impressively long sentence longer ... I'm
thinking of something like

If an RTP sender has negotiated ECN support for an RTP session, and has
successfully initiated ECN use on the path to the receiver [RFC6679], then
ECN-CE marked packets SHOULD be treated as if they were lost when
calculating if the congestion-based RTP circuit breaker (Section 4.3) has
been met, unless the RTP implementation can determine that ECN-CE marking
on this path is not reliable.

Is that something like what we were saying in the previous exchange?

Thanks,

Spencer

--

---

From: Colin Perkins <[email-masked]>
Date: Tue, 26 Apr 2016 23:36:27 +0100

Hi,

> On 26 Apr 2016, at 23:28, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Colin,
> 
> On Tue, Apr 26, 2016 at 5:13 PM, Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> > On 26 Apr 2016, at 23:08, Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hi, Colin,
> >
> > On Tue, Apr 26, 2016 at 9:43 AM, Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >> Spencer,
> >>
> >>> On 20 Apr 2016, at 02:20, Spencer Dawkins <[email-masked] <mailto:[email-masked]>> wrote:
> >>>
> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> >>> The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ <https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/>
> >>>
> >>>
> >>>
> I think the point that had my shoelaces tied together was the incongruity of an RTP implementation itself with expectations. 
> 
> If you can come up with text that says something like "or can be reasonably expected to have dissipated, based on the amount of time that has elapsed since the circuit breaker has tripped", or whatever else you're thinking of, that would have helped me.
> 
> (I’m assuming that the only thing an implementation has to work with when it hasn't received information that congestion has dissipated, would be the passage of time, but you'd know better what would be reasonable here)

It could also be something like a mobile device, that knows it’s now in a new location, and so might have a different path. I can give some examples, maybe?

> Yes, that’s one possible scenario. I can’t find it now, but I also seem to recall Apple reporting on strange experiences with ECN at a recent IETF.
> 
> Yum.
>  
> > explicit. If you want to try to make that happen, I'm happy to chat further
> 
> Happy to revise, if you think it would help. It’s better to make this clear, if we can.
> 
> So, at the risk of making an impressively long sentence longer ... I'm thinking of something like
> 
> If an RTP sender has negotiated ECN support for an RTP session, and has successfully initiated ECN use on the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD be treated as if they were lost when calculating if the congestion-based RTP circuit breaker (Section 4.3) has been met, unless the RTP implementation can determine that ECN-CE marking on this path is not reliable.
> 

Makes sense.

Do you want me to submit an update now, or hold off for a while?

-- 
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Tue, 26 Apr 2016 23:13:23 +0100

Hi,

> On 26 Apr 2016, at 23:08, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Colin,
> 
>>> The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/
>>> 
>>> 
>>> 

Yup.

-- 
Colin Perkins
https://csperkins.org/

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 26 Apr 2016 18:05:53 -0500

Hi, Colin,

On Tue, Apr 26, 2016 at 5:36 PM, Colin Perkins <[email-masked]> wrote:

> If you can come up with text that says something like "or can be
> reasonably expected to have dissipated, based on the amount of time that
> has elapsed since the circuit breaker has tripped", or whatever else you're
> thinking of, that would have helped me.
>
> (I’m assuming that the only thing an implementation has to work with when
> It could also be something like a mobile device, that knows it’s now in a
> new location, and so might have a different path. I can give some examples,
> maybe?
>

That would be terrific.

This is my own personality quirk (and yes, there's a recall procedure for
quirky ADs), but I prefer "SHOULD unless reasons like" to bare SHOULDs,
which in my experience have tended to turn up as "SHOULD unless it's
inconvenient to implement" for some implementers.

But beyond my own quirkiness, it's likely that in five years, most new
implementations will be done by people who don't have the depth of
experience with RTP that you do, so giving them examples may be pretty
helpful ...

>> Yes, that’s one possible scenario. I can’t find it now, but I also seem
>> to recall Apple reporting on strange experiences with ECN at a recent IETF.
>
>
> Yum.
>
>

I'll defer to Magnus and Ben, but I'm going to be happy with whatever you
do above.

And thanks again.

Spencer

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 27 Apr 2016 11:20:43 -0500

On 26 Apr 2016, at 18:05, Spencer Dawkins at IETF wrote:

> I'll defer to Magnus and Ben, but I'm going to be happy with whatever 
> you do above.

Colin: Please submit the update as soon as you can. (But warn me if the 
update is likely to happen in the last few days before the 
telechat--i.e. later than this week.)

Thanks!

Ben.

---

From: Colin Perkins <[email-masked]>
Date: Sat, 30 Apr 2016 23:03:11 +0100

> On 27 Apr 2016, at 17:20, Ben Campbell <[email-masked]> wrote:
> 
>> I'll defer to Magnus and Ben, but I'm going to be happy with whatever you do above.
> 
> Colin: Please submit the update as soon as you can. (But warn me if the update is likely to happen in the last few days before the telechat—i.e. later than this week.)

Done. Changes are as follows:

In Section 4.5, clarify the end of the first paragraph, about when an implementation might reasonably expect congestion to have dissipated.

In Section 7, clarify why ECN-CE marked packets “SHOULD” be treated as lost, rather than "MUST" be treated as lost, due to the unreliability of ECN marking on some paths.

Cheers,
Colin

-- 
Colin Perkins
https://csperkins.org/