Re: [icnrg] [Ndn-interest] Congestion Control related draft

Klaus Schneider <> Thu, 08 August 2019 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 21F5D120192 for <>; Thu, 8 Aug 2019 12:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j8hE7SdP-BB5 for <>; Thu, 8 Aug 2019 12:43:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6D03120183 for <>; Thu, 8 Aug 2019 12:43:56 -0700 (PDT)
Received: by with SMTP id l9so93400702qtu.6 for <>; Thu, 08 Aug 2019 12:43:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=OomVqqF+dAEsmIZ6bhGtPDUtQqmd7cJaN6SBrRv+gJ0=; b=eKreSBEgr7ZYHKrcvHJj5UT0aZ9ZgewSG9RBs49dYPxp/vPVYTQn3PPTXH7yNgZnAG toKv0N+4gfuGrxSGsHglMSJg83dKbILGF0tWp1aiPySzkr4rRJTZx1hfGJkGOQsxDCtn dmCQGowOE6sOl1gLAnZn8NyCJN0UZ0IoRaLAueSjt7RccSlfOV2rQXhZa4OcFnWxgPdm DFWlvJ0UROfgzAzbxY2FCcTmRiXqlyYGzGKJOxak+KzEPOTx2jdt4Lu0DN9gDU81vaMb q5tOJyO5zS08dsRspv6zk29BfJv75OxPzfCj/FGgSG4jim4zLgWuSFjyIs/vN5M8Ompt MmFw==
X-Gm-Message-State: APjAAAVzLuvU3ssAlaIabHbsbagys5BN/81Q49UFXMqRL/3WQ67EoCzk /83VvEp1lCZtN9Y0Zrw246D190RCYgQ=
X-Google-Smtp-Source: APXvYqxs3mxPZ5xFj06jkU7mwtxIJoCcdzL41/LcE1pa/DPFOWmQZ5B4kdB82xGFMJzeHuRZQKiJ4g==
X-Received: by 2002:aed:3f47:: with SMTP id q7mr14828097qtf.209.1565293435693; Thu, 08 Aug 2019 12:43:55 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id r4sm61101656qta.93.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Aug 2019 12:43:55 -0700 (PDT)
To: "David R. Oran" <>, ndn-interest <>,
References: <>
From: Klaus Schneider <>
Organization: University of Arizona
Message-ID: <>
Date: Thu, 8 Aug 2019 12:43:53 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [icnrg] [Ndn-interest] Congestion Control related draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Aug 2019 19:43:59 -0000

Dear Dave,

Thanks for the draft. I want to ask a related question.

As far as I understand, the Hop-by-Hop flow balance congestion control 
makes the following two assumptions:

1. The capacity of each link is fixed and you know its value (e.g. 10 Gbps)
2. You can access the current queue size/occupancy of each outgoing link 
(to check if it is congested)

I think these assumptions are fine for most networks, but I want to ask 
about a special case where they don't hold.

Specifically, consider a global ICN testbed deployment where NDN routers 
are connected via IP tunnels that span an unknown number of IP routers.

Here, you don't know the effective tunnel capacity (since there is an 
unknown amount of IP traffic). You can access the local router queue 
occupancy, but it's not very useful (since congestion can happen between 
two of the IP routers inside the tunnel).

Assume you have full control over the NDN routers, but no control over 
the IP routers. You can choose TCP or UDP tunnels.

How would you design the congestion control?

There are some existing designs for this case (e.g. 
But none of them have been tested much in practice.

Best regards,

On 8/3/19 7:14 AM, David R. Oran wrote:
> NDN folks,
> Those of you interested in congestion control for NDN might care to take 
> a look at the draft I submitted to ICNRG about doing a better job of 
> resource allocation than current interest-counting schemes. You can find 
> it at:
> 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 
> NDN or 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.
> I’d appreciate it if you’d post your comments on the ICNRG list 
> <> in order to have one place to discuss it. However, if 
> you’d prefer to reply to non-interest or to me privately, that’s ok as 
> long as you don’t mind if I repost responses and further discussion in 
> 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!
> DaveO
> _______________________________________________
> Ndn-interest mailing list