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 > >> > > > > >
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… Michael Welzl
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… De Schepper, Koen (Nokia - BE)
- Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on ch… Colin Perkins
- Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on ch… Black, David
- Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on ch… Michael Welzl
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… Ruediger.Geib
- Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on ch… Colin Perkins
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… Colin Perkins
- Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on ch… Black, David
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… Fred Baker (fred)
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… John Leslie
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… Fred Baker (fred)
- Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on ch… Michael Welzl
- Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on ch… Colin Perkins
- Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on ch… Michael Welzl
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… Black, David
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… Michael Welzl
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… De Schepper, Koen (Nokia - BE)
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… gorry
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… De Schepper, Koen (Nokia - BE)
- Re: [AVTCORE] [rtcweb] WG Last Call on changes: d… Ben Campbell
- Re: [AVTCORE] [rtcweb] WG Last Call on changes: d… Magnus Westerlund
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… Michael Welzl
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… Black, David
- Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on ch… Gorry (erg)
- Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on ch… Mirja Kühlewind
- Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on ch… Black, David
- Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on ch… Colin Perkins
- Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on ch… John Leslie
- Re: [AVTCORE] [tsvwg] WG Last Call on changes: dr… Black, David
- Re: [AVTCORE] [tsvwg] WG Last Call on changes: dr… Colin Perkins
- Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on ch… Michael Welzl
- Re: [AVTCORE] [tsvwg] WG Last Call on changes: dr… Black, David
- Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on ch… John Leslie
- Re: [AVTCORE] [tsvwg] WG Last Call on changes: dr… Magnus Westerlund
- [AVTCORE] WG Last Call on changes: draft-ietf-avt… Magnus Westerlund
- Re: [AVTCORE] [tsvwg] WG Last Call on changes: dr… Black, David