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

"Fred Baker (fred)" <> Mon, 27 June 2016 23:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDD0612DA5E; Mon, 27 Jun 2016 16:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -115.947
X-Spam-Status: No, score=-115.947 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 Kkr2BdaOeAHY; Mon, 27 Jun 2016 16:03:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 90F7C12DA65; Mon, 27 Jun 2016 16:03:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3195; q=dns/txt; s=iport; t=1467068598; x=1468278198; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VAaZX0ROdLwNmX7qcO2RWkRfiRBl3ZH9DbVzO3DLVzc=; b=HQ39jH8Q2tK/fOOhZVqLnFCmA7m7/fxKzwcmXVHbsJ6+CW5mjyBY/fTj bhYZmTgRiVY/hVKsctB7A6KqLciDcR+lcN/AMlktbgd2XBGIscjaeo9fV e1TJ/szpGOoR81xaD6V7UO+XC9Rqy9/EVLDFQzN4tb7Yj8nfT/Oqcof5r c=;
X-Files: signature.asc : 833
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALBQB8sHFX/5ldJa1bgz6BUwa6J4F7h?= =?us-ascii?q?hgCgTI6EgEBAQEBAQFlJ4RNAQEEeRACAQgYLjIlAgQOBQ6IIsB2AQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEPDogfCIJOh2yCLwWZAQGDLYFsiR2PJI9+ASUCLYI7gTVui?= =?us-ascii?q?Hh/AQEB?=
X-IronPort-AV: E=Sophos;i="5.26,538,1459814400"; d="asc'?scan'208";a="290689781"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2016 23:03:04 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u5RN34Uf012273 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jun 2016 23:03:04 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Jun 2016 18:03:03 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Mon, 27 Jun 2016 18:03:03 -0500
From: "Fred Baker (fred)" <>
To: John Leslie <>
Thread-Topic: [tsvwg] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16
Thread-Index: AQHR0MgPJk4Q/dpdG0yJgW1TNb0Iow==
Date: Mon, 27 Jun 2016 23:03:03 +0000
Message-ID: <>
References: <> <> <20160614135927.GE39331@verdi>
In-Reply-To: <20160614135927.GE39331@verdi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-mailer: Apple Mail (2.3124)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_CBB13F8A-4654-4CDB-8827-72DE6F3DD0E1"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: <>
Cc: Magnus Westerlund <>, "Black, David" <>, "" <>, IETF AVTCore WG <>, tsvwg <>
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: Mon, 27 Jun 2016 23:03:24 -0000

On Jun 14, 2016, at 6:59 AM, John Leslie <> wrote:
>   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'm not sure I agree.

I tend to think that ECN is relatively cheap - it asks the sender to reduce its effective window but doesn't make him retransmit anything and causes no delivery delay - while packet loss is relatively expensive in that it makes the sender retransmit and introduces at least a one RTT hiccup ( to detect and retransmit the lost packet) in the transmission stream. Neither actually changes the rate at which anyone sends (we talk about the signal asking the sender to slow down, but the rate demonstrably doesn't actually change - we're asking the sender to not pack the pipe so full).

When ECN does ask someone to reduce their effective window, if they are typically increasing it by one per RTT, ECN could very logically reduce it by a small amount, such as two or three. If it reduced it by two, for example, that would cause it to skip the next two transmission opportunities (the next two received acknowledgements, which might actually arrive in the same ack), and would be back to the same level two RTTs later. If ECN is typically keeping the delay relatively shallow, it is oscillating between "a little shallower" and " a little less shallow". So it gets CE every other RTT? So what? If I'm dropping a packet, or a couple of packets, every other RTT, we're going to see notes on NANOG and other lists. "Your network's broken again. It's dropping packets."

I could be argued into setting the CE threshold a little lower than the discard threshold. There are probably some mechanisms we'd do well to explore, but...