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

[Michael Welzl <[e-mail]>]

> On 27. jun. 2016, at 21.12, De Schepper, Koen (Nokia - BE) <[e-mail]> wrote:
> 
> 
>> -----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?

Yes you can construct an AQM mechanism to act precisely like that.
Do we want rules that make every other behavior “illegal” ?  Should this really be how end systems should interpret all forms of CE-marking?

I think we both would agree that the answer is no: both the L4S and the ABE work are based on the premise that a CE-mark does *NOT* necessarily mean the same as packet loss would.

So I agree with Gorry here - a circuit breaker is a bit of a special beast. It really mustn’t trigger by accident.

Cheers,
Michael



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