[icnrg] Some background on draft-oran-icnrg-flowbalance-00.txt

"David R. Oran" <daveoran@orandom.net> Fri, 02 August 2019 14:56 UTC

Return-Path: <daveoran@orandom.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AF84B120173 for <icnrg@ietfa.amsl.com>; Fri, 2 Aug 2019 07:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fErT40187cdV for <icnrg@ietfa.amsl.com>; Fri, 2 Aug 2019 07:56:23 -0700 (PDT)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19A9120020 for <icnrg@irtf.org>; Fri, 2 Aug 2019 07:56:23 -0700 (PDT)
Received: from [] ([IPv6:2601:184:4081:19c1:5d74:cc89:3503:46cf]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id x72EuKi7021297 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO) for <icnrg@irtf.org>; Fri, 2 Aug 2019 07:56:22 -0700
From: "David R. Oran" <daveoran@orandom.net>
To: ICNRG <icnrg@irtf.org>
Date: Fri, 02 Aug 2019 10:56:19 -0400
X-Mailer: MailMate (1.12.5r5643)
Message-ID: <F3450525-2EDB-4AB3-8909-3EB55F6245C4@orandom.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/gtimqmNmMx_VGGJJNgIkm-4owJo>
Subject: [icnrg] Some background on draft-oran-icnrg-flowbalance-00.txt
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Aug 2019 14:56:26 -0000

<Chair hat off> (obviously)

I just submitted 

This is something I’ve been noodling on for a long time because of my 
continuing interest in congestion control for ICN. It derives from some 
work I did at Cisco a few years ago which I believe has become timely. A 
number of interesting ICN use cases have either highly variable (e.g. 
video), very large (e.g. scientific data), or very small (e.g. IoT 
sensor) data objects, while all the congestion control schemes currently 
published (to my knowledge) only do interest counting which can’t 
account for this variability.

I’m obviously super-interested in what people think of this approach. 
It is deceptively simple (only requires one new TLV with easy switch 
from interest counting to fine-grained byte-based resource control for 
congestion and possibly QoS extensions). However, like most things with 
CCNx, it has interesting subtleties with respect to interest aggregation 
and consumers trying to game the system, both of which are covered in 
the spec.

As a final note, this has Cisco IPR on it. I’ve talked to the Cisco 
folks and they’ll put in the usual Cisco IETF-oriented IPR declaration 
when they get back from vacation (i.e. don’t hold your breath).

Thanks much!