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

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:
>> <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
>>
>> _______________________________________________
>> icnrg mailing list
>> icnrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/icnrg
>>

DaveO