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

["De Schepper, Koen (Nokia - BE)" <[e-mail]>]

> -----Original Message-----
> From: Black, David [mailto:[e-mail]]
> Sent: maandag 27 juni 2016 22:10
> To: De Schepper, Koen (Nokia - BE)
> Cc: tsvwg; IETF AVTCore WG; [e-mail]; Black, David
> Subject: RE: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-
> ietf-avtcore-rtp-circuit-breakers-16
> 
> > 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,

And I hope for ect(0) the network will keep doing this in the future, at 
least not to deviate too far from this.
L4S proposes to use ect(1) just because it deviates too much, so the network 
can detect the different end-system behavior and can couple it correctly to 
what it is doing for drop and ect(0).


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

Do you mean that this results in different mark and drop probabilities 
for competing ECN and non-ECN flows?

The impact on the dropping/marking probability *value* applied by an AQM can change 
due to presence of ECN flows, but I don't think this results in a different 
drop compared to mark probability. Up to now all classic AQMs smooth their p 
over sufficient long time to remove short fluctuations in queue sizes. 

From an end system I think for classic ECN it is safe to assume that if you 
detect high levels of drop, it means there is a high level of 
congestion AND the network takes care of it. If you detect a high level
of marking, it means lots of congestion and nobody is currently taking care 
of it. Everybody is looking at you as a sender to take care of it. That's why
I think you should not use ECN if you don't use congestion control.

It also means that the competing drop flows are having a high level of matching
drop. That's why I think a classic circuit breaker should also treat drop and 
classic marking similar.

I understood ABE tries to modify the end system behavior slightly for ECN. If 
this can be done safely with benefits that outweighs the disadvantages, 
than that's no problem, but I think nobody is in favor to modify the AQM 
behavior to ect(0).

Based on DualQ compatibility experiments with classic ECN, I also believe 
that, if we want to further promote classic ECN too, we need some extra 
safety measures for classic AQMs using ECN to avoid high CE marking levels, 
where ect(0) flows start to push away too much the non-ect flows. For 
instance PIE has (for good reasons) a max of 10% marking, and then switches 
to drop. As far as I know such measures are not mandatory in other ECN/AQM 
related drafts, is it?

Koen.

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