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

[[e-mail]]

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