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

John Leslie <> Tue, 14 June 2016 13:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B883D12D759; Tue, 14 Jun 2016 06:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.026
X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aEEbiEgX6_FW; Tue, 14 Jun 2016 06:59:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0E44712D74D; Tue, 14 Jun 2016 06:59:33 -0700 (PDT)
Received: by (Postfix, from userid 104) id 9BA06C9418; Tue, 14 Jun 2016 09:59:27 -0400 (EDT)
Date: Tue, 14 Jun 2016 09:59:27 -0400
From: John Leslie <>
To: "Black, David" <>
Message-ID: <20160614135927.GE39331@verdi>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
Archived-At: <>
Cc: Magnus Westerlund <>, "" <>, IETF AVTCore WG <>, tsvwg <>
Subject: Re: [AVTCORE] [rtcweb] [tsvwg] 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: Tue, 14 Jun 2016 13:59:35 -0000

Black, David <> wrote:
> In the new ECN text in Section 7, I see:
>    Given the above issues, implementations MAY ignore ECN-CE marks when	
>    determining if the congestion circuit breaker triggers, since	
>    excessive persistent congestion will eventually lead to packet loss	
> I think "MAY" is inappropriate here - this text reads like a "SHOULD NOT"
> requirement with an explanation of what happens when something else
> is done.

   I'm very sympathetic to your issue: there are implementations of ECN
out there which _will_not_ drop an ECN-capable packet before the sending
queue has overflowed.

   But at the same time, we're headed into changes where ECN-CE marking
will become more frequent than packet-drop.

   We must find a way to avoid ECN-CE triggering the congestion circuit
breaker when the forwarding node has not reached a level of congestion
which could trigger packet loss.

   I'd prefer language (perhaps in an RFC-3168-bis) stating that packet
drop MUST me used, at least occasionally, on packets which would be
ECN-CE marked, when the overall congestion at that node reaches the
drop level for non-ECN-capable packets. (The forwarding node is the only
node with sufficient information to see the issue.)

   (I recommend folks interested in circuit-breaker pay attention to the
L4S BoF being scheduled for Berlin.)

John Leslie <>