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

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

On 4 Aug 2019, at 2:37, Naveen Nathan wrote:

> See responses below.
>
> - Naveen
>
> On Sun, 4 Aug 2019, at 12:08 AM, David R. Oran wrote:
>>> [...]
>>> 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?
>
> 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.
>
Makes sense to add this to Section 3. I did that and it will be in the 
next version posted.

>>> 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?
>
> Yes. But I forgot to say earlier that it should be mentioned in the 
> end
> of section 1 (the introduction).
>
Also done, with references to min-max and proportional fairness in 
Wikipedia.

>>> 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.
>
> 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.
>
Good idea, I added a slightly edited version of what I wrote above.

> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO