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

From: "David R. Oran" <[email-masked]>
Date: Fri, 02 Aug 2019 10:56:19 -0400

<Chair hat off> (obviously)

I just submitted 
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 
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!

DaveO

---

From: "David R. Oran" <[email-masked]>
Date: Sat, 03 Aug 2019 09:13:35 -0400

On 3 Aug 2019, at 7:41, Naveen Nathan wrote:

> (response off-list)
Do you mind if I post this reply to the list? These are really good 
comments.

> I briefly read the draft. My CCNx/NDN is a bit rusty, so excuse my 
> ignorance
> below.
>
> First minor corrections:
>   - "nunce" -> "nuance"
>   - "obver-" (allocation) -> "over-" (allocation)
>   - "reasonable algorithm is in sue" -> "[...] use"
>   - "Dealing with for malicious actors" -> minus "for"
>
Fixed in my local copy. Will re-post once more comments come in.

> Regarding the consumer under-estimating (i.e. too big objects), I 
> think it
> might be good to elaborate on a different dimension such a lossy 
> versus
> lossless protocols. E.g. video streaming can deal with a loss of a 
> large
> object, and be informed of what to request in subsequent chunks. But 
> this can
> get tricky with VBR style encoding. But perhaps this is actually a bad 
> example
> since most video stream will use a manifest mechanism so requests 
> would have
> accurate estimates.
>
The issue here isn’t the loss, since any dynamic congestion control 
algorithm will either wind up under-allocating bottleneck links by a 
large fraction, or occasionally allow buffers to overflow and drop 
packets. I didn’t put much of a tutorial on basic congestion control 
in the document since the reader is assumed familiar with the cited 
references. What may be worth reiterating is that even congestion 
control algorithm has an explicit fairness goal and associated objective 
function (usually either min-max fairness or proportional fairness). If 
your fairness is to be based on resource usage, pure interest counting 
doesn’t do the trick, since a consumer asking for large thing can 
saturate a link and shift loss to consumers asking for small things.

Does that make sense? Should the document say more about this?

> I also think you should mention that this mechanism can be used to 
> inform a
> congestion control algorithm. I do note that this is explicitly 
> mentioned in
> section 3.
>
Hmmm, maybe I need to be more direct?

> About section 3.4. where you describe interest aggregation. You 
> recommend the
> second policy of giving a large object to correctly/over-estimating 
> consumers,
> whereas underestimating consumers get T_MTU_TOO_LARGE (also does "MTU" 
> make
> sense instead of "REQUEST"?). Shouldn't all consumers get it, if the 
> link isn't
> congested? I think this T_MTU_TOO_LARGE should only be sent if there's
> contention on the link and insufficient bandwidth can be allocated.
>
That’s of course a possibility. I decided recommending the error for 
the following reasons (which perhaps ought to be explicitly stated in 
the spec):
1. The link can be congested quite quickly after the queuing decision is 
made, especially if the data has a long link-occupancy time, so this is 
a safer alternative.
2. The cost of returning the error is only one link RTT, since the 
consumer can immediately re-issue the interest with the correct size and 
pick up the cached object from the upstream forwarder’s CS.
3. I tried to completely avoid the issues of aggregate resource control 
and the associated billing swamp, since returning the data raises the 
messy issue of whether to “charge” the actual used bandwidth to the 
consumer, or only the requested bandwidth through the expected data 
size. The rabbit hole goes deeper if you add differential QoS to the 
equation (another subject intentioanally not talked about in the 
document for many reasons) as consumers “playing games” and 
intentionally underestimating so their interests get satisfied when 
links aren’t congested gets you into all the considerations of 
malicious actors discussed later.

> As for my opinion: I really like it, it's a simple technique, and 
> optional to
> consumers and routers. I hope Cisco IPR people can allow its use 
> without
> restriction.
>
Thanks for the support! As long as the Cisco folks use their regular IPR 
terms, for experimental RFCs the terms in the past have said “free to 
use” for anybody complying with the spec as approved by the IETF/IRTF.

> - Naveen
>
> On Sat, 3 Aug 2019, at 12:56 AM, David R. Oran wrote:
>> _______________________________________________
>> icnrg mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/icnrg
>>

DaveO

---

From: "Naveen Nathan" <[email-masked]>
Date: Sun, 04 Aug 2019 16:37:13 +1000

See responses below.

- Naveen

On Sun, 4 Aug 2019, at 12:08 AM, David R. Oran wrote:
> > [...]

Yes, and yes.

So I think the congestion control algorithm (and knowledge these
algorithms lack) is sufficiently explained in section 3. I think you should
incorporate the point you made about fairness in the above response
in section 3 as well.

> Hmmm, maybe I need to be more direct?

Yes. But I forgot to say earlier that it should be mentioned in the end
of section 1 (the introduction).

> malicious actors discussed later.

I think it should be explicitly stated since intuitively if you have the
resources to send the data to the client, you would. But this is going
against the grain for the above reasons you stated.

---

From: "David R. Oran" <[email-masked]>
Date: Sun, 04 Aug 2019 10:21:30 -0400

Thanks again for these really useful follow-up comments. I hope to get 
comments from others before posting an updated draft.

> incorporate the point you made about fairness in the above response
Makes sense to add this to Section 3. I did that and it will be in the 
next version posted.

> of section 1 (the introduction).
Also done, with references to min-max and proportional fairness in 
Wikipedia.

> against the grain for the above reasons you stated.
Good idea, I added a slightly edited version of what I wrote above.

DaveO