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

John Leslie <john@jlc.net> Thu, 16 June 2016 22:25 UTC

Return-Path: <john@jlc.net>
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 07E5612DB45; Thu, 16 Jun 2016 15:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.026
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_vB2Jp_0XzS; Thu, 16 Jun 2016 15:25:52 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 60D2012D11E; Thu, 16 Jun 2016 15:25:52 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 31E1BC9416; Thu, 16 Jun 2016 18:25:48 -0400 (EDT)
Date: Thu, 16 Jun 2016 18:25:48 -0400
From: John Leslie <john@jlc.net>
To: "Black, David" <david.black@emc.com>
Message-ID: <20160616222548.GB77166@verdi>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362F589335@MX307CL04.corp.emc.com>
User-Agent: Mutt/1.4.1i
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/uu0or_staKwiyex5SUhFq__DwOo>
Cc: tsvwg <tsvwg@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Colin Perkins <csp@csperkins.org>, IETF AVTCore WG <avt@ietf.org>
Subject: Re: [AVTCORE] [rtcweb] [tsvwg] 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, 16 Jun 2016 22:25:54 -0000

Black, David <david.black@emc.com>; wrote:
> 
> ...  I view the current text as providing implementers with too much
> latitude to ignore ECN-CE marks (e.g., because an implementer doesn't
> want to think about this problem space in the first place).

   Understand, we have at least two proposals to make ECN-CE more frequent
than packet drop would be for non-ECN packets: possibly substantially
more frequent. Unless both are killed off, ECN-CE will show up frequently
enough that closing the flow on ECN-CE would kill too many connections.

   If you want circuit-breaking on such connections, there are two ways:
1. convince the forwarding nodes to drop packets if their queue exceeds
   design capacity; or
2. require the sender to send enough not-ECN-capable packets so that our
   receiver will see enough packet-drops when a circuit-breaker should
   activate.

   (I prefer the first option; but I wouldn't object to the second.)

   There really isn't any way for our circuit-breaker to know _how_much_
more frequent the ECN-CE marks may be. :^( We _will_ be sorry if we
allot the same frequency of CE packets as packet-drops to trigger the
circuit-breaker.

> Could someone propose initial text to qualifies the current "MAY ignore"
> statement?

   Essentially, for the second option, you might propose text to the
effect of:
] 
] If too many ECN-CE packets are received, the sender SHOULD send some
] not-ECN-capable packets to determine whether enough packets along the
] path are being dropped to justify activating our circuit-breaker.

   I'm not enthusiastic about adding that; but it would resolve the issue.

   BTW, I'm 100% convinced that either of the proposals being considered
in TSVWG could bring _substantial_ benefit to RTCWEB traffic.

--
John Leslie <john@jlc.net>;