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

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

> > But I’m less concerned than David about eventually ignoring it for circuit
> breaker.
> >
> Agree. Loss is the measurement that a CB MUST respond to.

Mumble.   I would be ok with a clear discouragement for use of ECN-CE marks, accompanied by the sort of design rationale here, or even better, a clear statement that lost packets for the purpose of the RTP circuit breaker have to be actually lost without getting into whether or not ECN-CE marks are involved -i.e., the RTP circuit breaker is specified against actual drops as a network protection backstop.

A related concern is that ECN marks may overstate equivalent loss behavior - a simplistic queue management discipline that marks every packet when the queue is over a threshold (NB: this class of marking behavior is NOT RECOMMENDED - a real AQM SHOULD be used) could yield a run of ECN-CE marks that would not cause a corresponding with a run of packet drops.   This is among the reasons that TCP reacts to ECN-CE marks only once per RTT, and might be a reason to treat multiple ECN-CE marks in an RTT interval as not representing drops of all packets for the RTP circuit breaker's TCP-equivalent throughput calculation.

Thanks, --David

> -----Original Message-----
> From: Gorry (erg) [mailto:[e-mail]]
> Sent: Saturday, June 18, 2016 2:23 AM
> To: Mirja Kühlewind
> Cc: Black, David; Magnus Westerlund; Colin Perkins; [e-mail]; IETF
> AVTCore WG; tsvwg
> Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-
> avtcore-rtp-circuit-breakers-16
> 
> I think we SHOULD NOT recommend to use ECN marks as inputs to a CB. See
> below:
> 
> > On 17 Jun 2016, at 16:02, Mirja Kühlewind <[e-mail]>
> wrote:
> >
> > +1 to not use normative language here.
> >
> > However, please note that having a high level of ECN-CE marks (without any
> losses) means that all packets were received correctly. This situation can even
> occurs without high delays (depending on the AQM used), which would just
> mean the services works perfectly. Therefore for me CE marks are a perfect input
> signal for a congestion control loop (where the AQM tell the sender to take action
> - whatever that means).
> 
> We may in future figure out ways to do this to detect significant failure using a
> rate adaptive transport and ECN e.g.  Observing 100% CE marks or something, for
> an RTP flow that is trying to send well below its peak rate decided by CC -- but I
> think this is speculating at an algorithm and adding details here is not a good idea.
> Especially as AQM continues to evolve.
> 
> > But I’m less concerned than David about eventually ignoring it for circuit
> breaker.
> >
> Agree. Loss is the measurement that a CB MUST respond to.
> 
> > In addition one point on something Magnus wrote earlier:
> > "If the implementation only have circuit breaker, i.e. no full fledged congestion
> controller and uses ECN, they can in worst case drive the buffer into the overload
> regime where it starts dropping packets. „
> >
> > I’m not sure about this case. ECN is an input signal for congestion control. If you
> don’t use congestion control but only a circuit breaker, you should probably not
> enable ECN. At least it not clear to me why you would enable it, and it's definitely
> not conform to the ECN spec. Probably we should say something about this in the
> draft...?
> >
> Agree, enabling ECN without a responsive CC is going to lead to trouble.
> 
> > Mirja
> >
> Gorry
> 
> >> Am 17.06.2016 um 16:03 schrieb 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/
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtcweb