Re: [icnrg] Beach reading!

["David R. Oran" <[e-mail]>]

Just getting to this - sorry for delay - deadlines…
Thanks much for the comments. Keep them coming!

On 12 Aug 2019, at 5:47, Dirk Kutscher wrote:

> Thanks for putting this together — nice reading indeed!
>
> No major objections — just a few thoughts:
>
> 1) The drafts mentions that in ICN, we may be able to leverage a richer set of forwarding behaviour that could be applied to equivalence classes. You didn’t use the term “forwarding strategy”, but it seems that ICN-QoS could effectively enable indirect control of link/storage/compute resources as well as of forwarding strategy decisions (for example, apply in-network INTEREST retransmissions, multicasting etc. for some classes). (Just wondered, whether you tried to avoid term deliberately.)
>
Gee…I thought I did. Here’s the text:

“Therefore, there are greenfield possibilities for more powerful QoS treatment options in ICN. For example, IP has no way to express a QoS treatment like "try hard to deliver reliably, even at the expense of delay or bandwidth". Such a QoS treatment for ICN could invoke native ICN mechanisms, none of which are present in IP, such as:
	* In-network retransmission in response to hop-by-hop errors returned from upstream forwarders
	* Trying multiple paths to multiple content sources either in parallel or serially
	* Higher precedence for short-term caching to recover from downstream errors
Such mechanisms are typically described in NDN and CCNx as forwarding strategies. However, little or no guidance is given for what application actions or protocol machinery is used to decide which forwarding strategy to use for which Interests that arrive at a forwarder. See [BenAbraham2018] for an investigation of these issues. Associating forwarding strategies with the equivalence classes and QoS treatments directly can make them more accessible and useful to implement and deploy”

I’m happy to include more examples, but this does seem to cover what you’re mentioning above.

>
> 2) On the control of cache resources, I agree that you don’t want to put consumer in *direct* control of cache resources. However, there could be circumstances where caching behaviour would be quite relevant to QoS-related forwarding. I am thinking of consumer mobility or critical IoT communication, where in-network repair would be useful. In such cases, the producers would not necessarily know what’s best with respect to caching, so there could be some value in a *indirect* consumer control/indication scheme for caching?
>
Yeah, I think I was too cavalier here. it’s actually a two-ended problem. Producers care about server load reduction and robustness against temporary disconnection or failure of servers. Consumers care about latency and temporary disconnection from their net at their end.

Consumers should be able to:
- advise upstream forwarders close to them to try to cache as a hedge against upstream disconnection
- advise forwarders at likely join points of a mobile edge to try to cache to reduce latency after a mobility event.

I suspect this can be done without any special cache-relay directives and be folded into QoS treatments related to latency and robustness. Interest steering could also play a role but since we don’t have any ICNRG drafts on that I don’t plan on mentioning it.

I’ll come up with some better text for the next version.

> Thanks,
> Dirk
>
>
> On 9 Aug 2019, at 22:21, David R. Oran wrote:
>
>> Happy August, ICNRGers.
>>
>> I just submitted the draft below on constructing an architecture for achieving QoS for ICN protocols. It’s an expansion of the stuff I’ve been pounding into people’s heads at multiple ICNRG meetings as a presentation. I thought formalizing it as a document for consideration by ICNRG to guide our work might be timely. Please take a look and post feedback and comments.
>>
>> It might be good beach reading, especially if you like to nod off in the sun :-)
>>
>> DaveO
>>
>> Forwarded message:
>>
>>> From: [e-mail]
>>> To: [e-mail]
>>> Subject: I-D Action: draft-oran-icnrg-qosarch-00.txt
>>> Date: Fri, 09 Aug 2019 13:16:57 -0700
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>>         Title           : Considerations in the development of a QoS Architecture for CCNx-like ICN protocols
>>>         Author          : Dave Oran
>>> 	Filename        : draft-oran-icnrg-qosarch-00.txt
>>> 	Pages           : 18
>>> 	Date            : 2019-08-09
>>>
>>> Abstract:
>>>    This is a position paper.  It documents the author's personal views
>>>    on how Quality of Service (QoS) capabilities ought to be accommodated
>>>    in ICN protocols like CCNx or NDN which employ flow-balanced
>>>    Interest/Data exchanges and hop-by-hop forwarding state as their
>>>    fundamental machinery.  It argues that such protocols demand a
>>>    substantially different approach to QoS from that taken in TCP/IP,
>>>    and proposes specific design patterns to achieve both classification
>>>    and differentiated QoS treatment on both a flow and aggregate basis.
>>>    It also considers the effect of caches as a resource in addition to
>>>    memory, CPU and link bandwidth that should be subject to explicitly
>>>    un-fair resource allocation.  The proposed methods are intended to
>>>    operate purely at the network layer, providing the primitives needed
>>>    to achieve both transport and higher layer QoS objectives.  It
>>>    explicitly excludes any discussion of Quality of Experience (QoE)
>>>    which can only be assessed and controlled at the application layer or
>>>    above.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-oran-icnrg-qosarch-00
>>> https://datatracker.ietf.org/doc/html/draft-oran-icnrg-qosarch-00
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> _______________________________________________
>> icnrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/icnrg


> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO