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

[Mirja Kühlewind <[e-mail]>]

+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). But I’m less concerned than David about eventually ignoring it for circuit breaker.

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

Mirja


> 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