[Ndn-interest] Congestion Control related draft

[Klaus Schneider]

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. 
http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p21-schneider.pdf 
https://datatracker.ietf.org/meeting/interim-2017-icnrg-03/materials/slides-interim-2017-icnrg-03-sessa-icn-congestion-control-how-handle-unknown-and-varying-link-capacity-ahlgren/). 
But none of them have been tested much in practice.

Best regards,
Klaus






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:
> 
> https://datatracker.ietf.org/doc/draft-oran-icnrg-flowbalance/.
> 
> 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 
> <icnrg at irtf.org> 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 
> ICNRG.
> 
> 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
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest