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

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

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