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

"De Schepper, Koen (Nokia - BE)" <koen.de_schepper@nokia-bell-labs.com> Mon, 27 June 2016 19:12 UTC

Return-Path: <koen.de_schepper@nokia-bell-labs.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A1512D7F8; Mon, 27 Jun 2016 12:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unfi0uI2xgCz; Mon, 27 Jun 2016 12:12:55 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC35A12D7D1; Mon, 27 Jun 2016 12:12:54 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id B03A0F90A1507; Mon, 27 Jun 2016 19:12:48 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5RJCpTx026670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Jun 2016 19:12:52 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5RJCpZH011789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jun 2016 21:12:51 +0200
Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.240]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 27 Jun 2016 21:12:51 +0200
From: "De Schepper, Koen (Nokia - BE)" <koen.de_schepper@nokia-bell-labs.com>
To: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>
Thread-Topic: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16
Thread-Index: AQHRyB4Xv7l4815Xu02SCqscZNZxsp/tUDQAgABAKwCAABBvgIABAQmAgAOYcQCAADeCAIAK/Ekg///0AQCAAFzOEA==
Date: Mon, 27 Jun 2016 19:12:50 +0000
Message-ID: <BF6B00CC65FD2D45A326E74492B2C19FB76A659B@FR711WXCHMBA05.zeu.alcatel-lucent.com>
References: <ccf9f2d7-2694-4336-0ec9-ccfebfeb0120@ericsson.com> <CE03DB3D7B45C245BCA0D243277949362F585D3E@MX307CL04.corp.emc.com> <d97e30a7-70f5-26d0-c3a4-0497c669f5f6@ericsson.com> <CE03DB3D7B45C245BCA0D243277949362F586054@MX307CL04.corp.emc.com> <D19E595F-7C66-4AE9-92B4-D550A93F634D@csperkins.org> <CE03DB3D7B45C245BCA0D243277949362F589335@MX307CL04.corp.emc.com> <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <CE03DB3D7B45C245BCA0D243277949362F596DBC@MX307CL04.corp.emc.com> <E16BEA87-1D0F-48F1-A9AC-2729079D581D@tik.ee.ethz.ch> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <CE03DB3D7B45C245BCA0D243277949362F59C41D@MX307CL04.corp.emc.com> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <BF6B00CC65FD2D45A326E74492B2C19FB76A6433@FR711WXCHMBA05.zeu.alcatel-lucent.com> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk>
In-Reply-To: <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/qF8JF8GIut0GrA72PIeOICNGlIw>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, tsvwg <tsvwg@ietf.org>, Michael Welzl <michawe@ifi.uio.no>, "Black, David" <david.black@emc.com>, IETF AVTCore WG <avt@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Colin Perkins <csp@csperkins.org>
Subject: Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2016 19:12:59 -0000

> -----Original Message-----
> From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk]
> Sent: maandag 27 juni 2016 17:38
> To: De Schepper, Koen (Nokia - BE)
> Cc: Michael Welzl; Black, David; gorry@erg.abdn.ac.uk; Magnus
> Westerlund; tsvwg; IETF AVTCore WG; rtcweb@ietf.org; 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:tsvwg-bounces@ietf.org] On Behalf Of Michael
> Welzl
> >> Sent: maandag 20 juni 2016 18:36
> >> To: Black, David
> >> Cc: <gorry@erg.abdn.ac.uk>; Fairhurst; Magnus Westerlund; tsvwg; IETF
> >> AVTCore WG; rtcweb@ietf.org; 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 <david.black@emc.com>;
> 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:gorry@erg.abdn.ac.uk]
> >> >> Sent: Saturday, June 18, 2016 2:23 AM
> >> >> To: Mirja Kühlewind
> >> >> Cc: Black, David; Magnus Westerlund; Colin Perkins;
> rtcweb@ietf.org;
> >> 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
> >> <mirja.kuehlewind@tik.ee.ethz.ch>;
> >> >> 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
> <david.black@emc.com>;:
> >> >>>>
> >> >>>> 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:csp@csperkins.org]
> >> >>>>> Sent: Friday, June 17, 2016 6:14 AM
> >> >>>>> To: John Leslie; Black, David
> >> >>>>> Cc: rtcweb@ietf.org; 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 <john@jlc.net>; wrote:
> >> >>>>>>
> >> >>>>>> Black, David <david.black@emc.com>; 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
> >> >>>> rtcweb@ietf.org
> >> >>>> https://www.ietf.org/mailman/listinfo/rtcweb
> >> >
> >
> >