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

["Naveen Nathan" <[e-mail]>]

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.

> > 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).

> > 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.