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

"Black, David" <> Tue, 28 June 2016 01:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0464412D7D1; Mon, 27 Jun 2016 18:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.747
X-Spam-Status: No, score=-5.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oRgaliwB9gGn; Mon, 27 Jun 2016 18:04:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 132B112D0AD; Mon, 27 Jun 2016 18:04:32 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5S14Rtp022619 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Jun 2016 21:04:27 -0400
X-DKIM: OpenDKIM Filter v2.4.3 u5S14Rtp022619
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=jan2013; t=1467075868; bh=GP3mzO+j5XxOL31gZdB8kCQpKfo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=EBNvq5m4lBjav/2/ABb1U1Mph3UR414wbwYGs9xoKYIdKz2N7hKMy5qX1t9B48tF/ XPMC8IyBaxDLYr8t3uO2nSoWtvkRO+pxxFdnliV9Gx25TBruawmEWsxncOHZp9/8EZ xAdHsnDr+zW0N+vv7PJNFFM2FamUjtaHf6sPqXsE=
X-DKIM: OpenDKIM Filter v2.4.3 u5S14Rtp022619
Received: from ( []) by (RSA Interceptor); Mon, 27 Jun 2016 21:03:52 -0400
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5S14C9f018610 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 27 Jun 2016 21:04:13 -0400
Received: from ([fe80::849f:5da2:11b:4385]) by ([]) with mapi id 14.03.0266.001; Mon, 27 Jun 2016 21:04:12 -0400
From: "Black, David" <>
To: Michael Welzl <>, Colin Perkins <>
Thread-Topic: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16
Thread-Index: AQHR0L+ZFj+KetGouEG7mSRAG7kvVJ/+KEcA///WaKA=
Date: Tue, 28 Jun 2016 01:04:11 +0000
Message-ID: <>
References: <> <> <> <> <> <> <20160616222548.GB77166@verdi> <> <> <> <> <> <> <> <> <> <CE03DB3D7B45C245BCA0D24327! 7949362F5> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Classifications: public
Archived-At: <>
Cc: "" <>, tsvwg <>, IETF AVTCore WG <>
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, 28 Jun 2016 01:04:35 -0000

Trying to shorten up this thread again ...

> >>> I'm not quite sure how to specify "use of ECN as additional evidence" of
> >>> "excessive congestion" as drop-equivalence is about the best we have
> >>> for current guidance.
> >>
> >> I fail to parse that sentence, so maybe I’m getting you wrong, but anyway I
> >> wonder: what’s even the point of this?
> >> Why even bother considering CE-marks as information for a circuit breaker?
> >
> > Because the alternative is that we only break the circuit once the queue has
> been driven into overflow, and packets have been lost. We want to avoid that,
> since it causes latency, and too much latency is very bad for the user experience.
> Well - the better way out would be for the application to react. Maybe this is me
> misunderstanding the circuit breaker, but I did think it’s more like a last resort…
> you just don’t want to be trigger-happy with such a thing?

Well, the RTP circuit breaker draft is not trigger happy - for its congestion circuit
breaker to trip, RTP has to be sending at 10x the rate that TCP would send under
those conditions, based on the TCP throughput equation.  See:

The issue here is - when calculating the comparable TCP throughput, how are ECN-CE
marks used to determine the loss rate input to the TCP throughput equation?  Do
ECN-CE marked packets count as having arrived or having been dropped?

When things are relatively stable and the ECN-CE marks are being used to nudge
the sender's rate based on what the network can absorb, whether ECN-CE marks
count as losses or not is probably immaterial - the 10x divergence from the TCP
throughput equation's rate is not going to arise, and the circuit breaker won't trip.
The circuit breaker is only supposed to trip when things are seriously wrong.

(1) If the RTP congestion circuit breaker trips based on ECN-CE marks alone,
something feels intuitively wrong - how'd we get to RTP running at 10x the
comparable TCP sending rate with no losses?  Perhaps the circuit breaker
shouldn't trip on ECN-CE marks alone?

(2) At the other extreme, the congestion circuit breaker clearly has to trip if RTP
gets to 10x the comparable TCP sending rate based on losses alone.  This is the
baseline for the circuit breaker to provide network protection as intended.

So, going back to Gorry's suggestion to use ECN-CE marks as "additional evidence,"
here's a straw proposal to shoot at ... factor in ECN-CE marks as additional losses
*only when* losses are already occurring.   

For example, we could specify that for the RTP congestion circuit breaker to trip, the
RTP sending rate has to be:
	- 10x the equivalent TCP sending rate based on counting ECN-CE marked
		packets as lost; AND
	- 3x the equivalent sending rate based on actual drops (i.e., counting
		ECN-CE marked packets as delivered).
The "3x" above is an off-the-top-of-my-head factor that attempts to roughly
equally weight the inputs (3 is close to the square root of 10) - pick a different
number if that weighting feels wrong.

This would force drops to occur and then consider ECN-CE marks as additional evidence
that something is wrong in the network.

Another possible rationale for this mixing is that if drops start occurring, then many of
the new and proposed uses of ECN that treat ECN-CE marks as less than loss-equivalent
are outside their intended operating envelopes/regions.

Thanks, --David