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

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

> As long as an AQM is marking at the same rate as dropping

That's an interesting assumption - it should be true for AQMs vetted
here in the past, but there are easy ways for it not to hold (e.g., if dropping
or marking is based on queue occupancy, it is possible that dropping
reduces queue occupancy in a fashion that marking does not).

For ECN "classic" (i.e., see RFC 3168) where ECN-CE markings are treated
as drop-equivalent, that is for congestion control purposes, which is similar
to, (but not the same as) the throughput estimation usage for the RTP circuit
breaker.    I'll note that ECN "classic" was designed congestion control
algorithms for react to ECN-CE marks once per RTT, independent of how
many ECN-CE marks are observed in an RTT.

Gorry wrote:

> > in this context we should use ECN to drive a CC algorithm and we should be
> > cautious to avoid requiring its use within a Circuit Breaker - optional
> > use, if you understand how to interpret a reaction to many CE-marks as
> > excessive congestion, are permitted.

Something like that may be workable, starting with a clear distinction between
the use of ECN by CC (routine, active at all times) and ECN by a circuit
breaker (monitors for evidence that things have gotten bad, only activated
when things get bad).   This would baseline the RTP circuit breaker on drops
and allow use of ECN as additional evidence of problems, in contrast to
congestion control where ECN-CE is effectively treated as drop-equivalent.

I'm not quite sure how to specify "use of ECN as additional evidence" of
"excessive congestion" as drop-equivalence is about the best we have
for current guidance.

Thanks, --David

> -----Original Message-----
> From: De Schepper, Koen (Nokia - BE) [mailto:koen.de_schepper@nokia-bell-
> labs.com]
> Sent: Monday, June 27, 2016 3:13 PM
> To: [e-mail]
> Cc: Michael Welzl; Black, David; Magnus Westerlund; tsvwg; IETF AVTCore WG;
> [e-mail]; Colin Perkins
> Subject: RE: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-
> avtcore-rtp-circuit-breakers-16
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: maandag 27 juni 2016 17:38
> > To: De Schepper, Koen (Nokia - BE)
> > Cc: Michael Welzl; Black, David; [e-mail]; Magnus
> > Westerlund; tsvwg; IETF AVTCore WG; [e-mail]; Colin Perkins
> > Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-
> > ietf-avtcore-rtp-circuit-breakers-16
> >
> > I think thinking of L4S is maybe off at a tangent. The question really
> > is
> > about the interpretation of loss and CE-mark as equivalent. I argued
> > that
> > each ECN-CE mark should not be counted as equivalent to a lost segment -
> 
> Why not? As long as an AQM is marking at the same rate as dropping, a
> 100% marking means that non-ecn flows are being dropped at a 100%, not?
> 
> Koen.
> 
> 
> > in this context we should use ECN to drive a CC algorithm and we should
> > be
> > cautious to avoid requiring its use within a Circuit Breaker - optional
> > use, if you understand how to interpret a reaction to many CE-marks as
> > excessive congestion, are permitted.
> >
> > Gorry
> >
> > > As far as I understand, this draft is related to circuit breakers in
> > > end-systems, right?
> > >
> > > It is the end system that determines the use of ECN (currently marking
> > > non-ect for drop and ect(0) for Classic ECN).
> > >
> > > In L4S we don't plan to change the behavior of Classic ECN, and ABE's
> > > behavior should be close to non-ABE ECN. So I guess there is no
> > problem of
> > > describing the behavior of how a Classic ECN based sender would
> > respond
> > > today.
> > >
> > > As we only want to significantly change the network behavior of ect(1)
> > > marking, can we solve this issue by recommending (or even requiring)
> > > senders to mark only ect(0) and describing the classic ECN circuit
> > > breaker? When L4S gets defined, also an L4S based circuit breaker
> > > extension can be defined for senders that want to use the L4S service
> > > (when senders send ect(1) packets).
> > >
> > > Regards,
> > > Koen.
> > >
> > >
> > >> -----Original Message-----
> > >> From: tsvwg [mailto:[e-mail]] On Behalf Of Michael
> > Welzl
> > >> Sent: maandag 20 juni 2016 18:36
> > >> To: Black, David
> > >> Cc: <[e-mail]> Fairhurst; Magnus Westerlund; tsvwg; IETF
> > >> AVTCore WG; [e-mail]; Colin Perkins
> > >> Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes:
> > draft-
> > >> ietf-avtcore-rtp-circuit-breakers-16
> > >>
> > >>
> > >> > On 20. jun. 2016, at 15.16, Black, David <[e-mail]>
> > wrote:
> > >> >
> > >> >>> 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.
> > >>
> > >> I’m not sure we need such complicated logic to find a case where
> > ECN
> > >> marks are different from packet drops:
> > >>
> > >> Basically, they simply aren’t - even “real” AQMs marking
> > isn’t
> > >> exactly
> > >> the same as a packet drop: the marks themselves inform you that an
> > AQM
> > >> did its job, and with modern AQMs like CoDel / PIE etc., you’re
> > >> probably
> > >> getting this from a shallow queue. Chances are that this is less than
> > a
> > >> BDP worth of queuing, which is our justification for recommending a
> > >> different back-off behavior in draft-khademi-tsvwg-ecn-response-00
> > and
> > >> draft-khademi-tcpm-alternativebackoff-ecn-00
> > >>
> > >> So the point is not that AQMs would treat ECN marking and dropping
> > >> differently - it’s that ECN indicates an AQM, and hence probably a
> > >> shallow queue. With a drop, you just don’t know.
> > >>
> > >> Back to the CB, I think an AQM marking at a shallow queue (like e.g.
> > >> CoDel) is indeed quite different from a “broken connection”.
> > >>
> > >> Cheers,
> > >> Michael
> > >>
> > >>
> > >> >
> > >> > 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
> > >> >
> > >
> > >