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

Michael Welzl <> Thu, 30 June 2016 16:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FD9412D16D; Thu, 30 Jun 2016 09:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.626
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v9FLU2j5cM5w; Thu, 30 Jun 2016 09:28:22 -0700 (PDT)
Received: from ( [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D306512D113; Thu, 30 Jun 2016 09:28:21 -0700 (PDT)
Received: from ([]) by with esmtp (Exim 4.80.1) (envelope-from <>) id 1bIep8-0005uh-1O; Thu, 30 Jun 2016 18:28:18 +0200
Received: from ([] helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <>) 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 <>
In-Reply-To: <>
Date: Thu, 30 Jun 2016 18:28:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <20160616222548.GB77166@verdi> <> <> <> <> <> <> <> <> <> <CE03DB3D7B45C245BCA0D243277949362F5> <>
To: "De Schepper, Koen (Nokia - BE)" <>
X-Mailer: Apple Mail (2.3124)
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: 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: <>
Cc: "Black, David" <>, "" <>, tsvwg <>, IETF AVTCore WG <>
Subject: Re: [AVTCORE] [tsvwg] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jun 2016 16:28:25 -0000


> On 30. jun. 2016, at 17.58, De Schepper, Koen (Nokia - BE) <> wrote:
>> -----Original Message-----
>> From: Black, David []
>> Sent: maandag 27 juni 2016 22:10
>> To: De Schepper, Koen (Nokia - BE)
>> Cc: tsvwg; IETF AVTCore WG;; 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:

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