Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16

["Black, David" <[e-mail]>]

Colin,

> >> ...  I view the current text as providing implementers with too much
> >> latitude to ignore ECN-CE marks (e.g., because an implementer doesn't
> >> want to think about this problem space in the first place).
> 
> I agree, but the argument is that doing so is less harmful than deploying a circuit
> breaker that triggers too often when ECN is used.
> 
> I’m not sure I believe this argument, though, since it seems that any new AQM
> that applies ECN marks much more often than at present will have to consider
> backwards compatibility, to work with deployed TCP (e.g., draft-briscoe-tsvwg-
> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new marking,
> while existing implementations set ECT(0)). These compatibility mechanisms
> would seem to prevent the issues with the circuit breaker too.

That roughly matches my line of thinking, and I'll observe that the original DCTCP
protocol design that used more aggressive ECN-CE marking was only safe for
Controlled Environment deployments.   See the TSVWG rfc5405bis draft for the
definition of Controlled Environment, and ignore the fact that the rfc5405bis
draft is a UDP draft - this definition is more broadly applicable.

Going back over Section 7 in this avtcore draft, my views are:

[A] None of these drafts justify a "MAY ignore" response to ECN-CE marks:
	- draft-khademi-tcpm-alternativebackoff-ecn
	- draft-ietf-rmcat-nada
	- draft-ietf-rmcat-scream-cc

[B] In line with Colin's comment on the L4S draft, I think it's incumbent on
the authors of draft-briscoe-aqm-dualq-coupled to figure out how that will
coexist (or avoid) deployed TCP, and this avtcore draft ought not to be
trying to prejudge what will be done there.

So, I don't think the current text in Section 7 has justified the unfettered
"implementations MAY ignore ECN-CE marks" text, as ignoring those marks
is not consistent with any of the four cited drafts.

In more detail, I think making changes to normative requirements here based
on [B] is premature, and I would hope that the rmcat WG could be encouraged
to consider the RTP circuit breaker in its congestion control drafts, as those CC
mechanisms are related to the circuit breaker mechanism, hence likely
to be in related areas of an RTP implementation.

That leaves draft-khademi-tcpm-alternativebackoff-ecn, which TSVWG
will be looking at in Berlin.  If a normative statement about ECN-CE reaction
is going to rest on that draft, then the reference to that draft should be
normative.  Something about doing that strikes me as premature ...

I realize that we're trying to predict and accommodate the future, which
is an imprecise undertaking at best.   As an alternative to the current text,
would it be reasonable to say (without any RFC 2119 keywords) that the
best current guidance is still to treat ECN-CE marks as indicating drops,
with a warning that there is a good possibility of this changing in the
near future due to all of the work in progress cited in Section 7?

Thanks, --David

> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: Friday, June 17, 2016 6:14 AM
> To: John Leslie; Black, David
> Cc: [e-mail]; IETF AVTCore WG; tsvwg
> Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-
> avtcore-rtp-circuit-breakers-16
> 
> 
> > On 16 Jun 2016, at 23:25, John Leslie <[e-mail]> wrote:
> >
> > Black, David <[e-mail]> wrote:
> >>
> >> ...  I view the current text as providing implementers with too much
> >> latitude to ignore ECN-CE marks (e.g., because an implementer doesn't
> >> want to think about this problem space in the first place).
> 
> I agree, but the argument is that doing so is less harmful than deploying a circuit
> breaker that triggers too often when ECN is used.
> 
> I’m not sure I believe this argument, though, since it seems that any new AQM
> that applies ECN marks much more often than at present will have to consider
> backwards compatibility, to work with deployed TCP (e.g., draft-briscoe-tsvwg-
> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new marking,
> while existing implementations set ECT(0)). These compatibility mechanisms
> would seem to prevent the issues with the circuit breaker too.
> 
> >   Understand, we have at least two proposals to make ECN-CE more frequent
> > than packet drop would be for non-ECN packets: possibly substantially
> > more frequent. Unless both are killed off, ECN-CE will show up frequently
> > enough that closing the flow on ECN-CE would kill too many connections.
> >
> >   If you want circuit-breaking on such connections, there are two ways:
> > 1. convince the forwarding nodes to drop packets if their queue exceeds
> >   design capacity; or
> > 2. require the sender to send enough not-ECN-capable packets so that our
> >   receiver will see enough packet-drops when a circuit-breaker should
> >   activate.
> >
> >   (I prefer the first option; but I wouldn't object to the second.)
> >
> >   There really isn't any way for our circuit-breaker to know _how_much_
> > more frequent the ECN-CE marks may be. :^(
> 
> This is a problem, both for the circuit breaker, and for the algorithms being
> defined in RMCAT. We do need some understanding what the expected marking
> rates are likely to be, so congestion control and circuit breakers can be defined.
> 
> > We _will_ be sorry if we
> > allot the same frequency of CE packets as packet-drops to trigger the
> > circuit-breaker.
> >
> >> Could someone propose initial text to qualifies the current "MAY ignore"
> >> statement?
> >
> >   Essentially, for the second option, you might propose text to the
> > effect of:
> > ]
> > ] If too many ECN-CE packets are received, the sender SHOULD send some
> > ] not-ECN-capable packets to determine whether enough packets along the
> > ] path are being dropped to justify activating our circuit-breaker.
> >
> >   I’m not enthusiastic about adding that; but it would resolve the issue.
> 
> I’m not convinced this would work. The circuit breaker is looking at long term
> trends, and in order to have enough not-ECT packets to determine if it should
> trigger, you’d essentially have to run without ECN for some seconds.
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
>