Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16
Michael Welzl <michawe@ifi.uio.no> Thu, 30 June 2016 16:28 UTC
Return-Path: <michawe@ifi.uio.no>
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 0FD9412D16D; Thu, 30 Jun 2016 09:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level:
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 v9FLU2j5cM5w; Thu, 30 Jun 2016 09:28:22 -0700 (PDT)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 D306512D113; Thu, 30 Jun 2016 09:28:21 -0700 (PDT)
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1bIep8-0005uh-1O; Thu, 30 Jun 2016 18:28:18 +0200
Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.107]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1bIep7-0007mS-8a; Thu, 30 Jun 2016 18:28:17 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <BF6B00CC65FD2D45A326E74492B2C19FB76A9923@FR711WXCHMBA05.zeu.alcatel-lucent.com>
Date: Thu, 30 Jun 2016 18:28:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CEEC9A70-B31D-495E-98BB-0E60CBC2487D@ifi.uio.no>
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> <BF6B00CC65FD2D45A326E74492B2C19FB76A659B@FR711WXCHMBA05.zeu.alcatel-lucent.com> <CE03DB3D7B45C245BCA0D243277949362F5 AEE02@MX307CL04.corp.emc.com> <BF6B00CC65FD2D45A326E74492B2C19FB76A9923@FR711WXCHMBA05.zeu.alcatel-lucent.com>
To: "De Schepper, Koen (Nokia - BE)" <koen.de_schepper@nokia-bell-labs.com>
X-Mailer: Apple Mail (2.3124)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 10 sum msgs/h 4 total rcpts 43919 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 5AE02707A5F73F64E8158E2EEAD77F4720030D04
X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1481 max/h 15 blacklist 0 greylist 0 ratelimit 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/WC7X_DOkyWFmNs1SCJO253fOEU0>
Cc: "Black, David" <david.black@emc.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, tsvwg <tsvwg@ietf.org>, IETF AVTCore WG <avt@ietf.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: Thu, 30 Jun 2016 16:28:25 -0000
Hi, > On 30. jun. 2016, at 17.58, De Schepper, Koen (Nokia - BE) <koen.de_schepper@nokia-bell-labs.com> wrote: > > >> -----Original Message----- >> From: Black, David [mailto:david.black@emc.com] >> Sent: maandag 27 juni 2016 22:10 >> To: De Schepper, Koen (Nokia - BE) >> Cc: tsvwg; IETF AVTCore WG; rtcweb@ietf.org; Black, David >> Subject: RE: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft- >> ietf-avtcore-rtp-circuit-breakers-16 >> >>> As long as an AQM is marking at the same rate as dropping >> >> That's an interesting assumption - it should be true for AQMs vetted >> here in the past, > > And I hope for ect(0) the network will keep doing this in the future, at > least not to deviate too far from this. > L4S proposes to use ect(1) just because it deviates too much, so the network > can detect the different end-system behavior and can couple it correctly to > what it is doing for drop and ect(0). > > >> but there are easy ways for it not to hold (e.g., if >> dropping >> or marking is based on queue occupancy, it is possible that dropping >> reduces queue occupancy in a fashion that marking does not). > > Do you mean that this results in different mark and drop probabilities > for competing ECN and non-ECN flows? > > The impact on the dropping/marking probability *value* applied by an AQM can change > due to presence of ECN flows, but I don't think this results in a different > drop compared to mark probability. Up to now all classic AQMs smooth their p > over sufficient long time to remove short fluctuations in queue sizes. > > From an end system I think for classic ECN it is safe to assume that if you > detect high levels of drop, it means there is a high level of > congestion AND the network takes care of it. If you detect a high level > of marking, it means lots of congestion and nobody is currently taking care > of it. Everybody is looking at you as a sender to take care of it. That's why > I think you should not use ECN if you don't use congestion control. > > It also means that the competing drop flows are having a high level of matching > drop. That's why I think a classic circuit breaker should also treat drop and > classic marking similar. > > I understood ABE tries to modify the end system behavior slightly for ECN. If > this can be done safely with benefits that outweighs the disadvantages, > than that's no problem, but I think nobody is in favor to modify the AQM > behavior to ect(0). I pretty much agree with everything here… > Based on DualQ compatibility experiments with classic ECN, I also believe > that, if we want to further promote classic ECN too, we need some extra > safety measures for classic AQMs using ECN to avoid high CE marking levels, > where ect(0) flows start to push away too much the non-ect flows. For > instance PIE has (for good reasons) a max of 10% marking, and then switches > to drop. As far as I know such measures are not mandatory in other ECN/AQM > related drafts, is it? … but here I’d like to put a note of warning: see the appendix here: http://heim.ifi.uio.no/michawe/research/publications/CAIA-TR-150710A.pdf here, we found that this behavior is detrimental (the 10% threshold was too small). => I agree with the general notion of such a threshold, but the threshold shouldn’t be too low (it can eliminate ECN’s benefits). Cheers, Michael
- 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