Subject: [icnrg] Beach reading!

From: "David R. Oran" <[email-masked]>
Date: Fri, 09 Aug 2019 16:21:17 -0400

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: [email-masked]
> To: [email-masked]
> 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
> [email-masked]
> 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

---

From: "Dirk Kutscher" <[email-masked]>
Date: Mon, 12 Aug 2019 14:47:15 +0200

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

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?

Thanks,
Dirk

On 9 Aug 2019, at 22:21, David R. Oran wrote:

> 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:
>
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: "David R. Oran" <[email-masked]>
Date: Sat, 17 Aug 2019 07:38:24 -0700

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:

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

>> 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:
>>
>>> 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
>>>    on how Quality of Service (QoS) capabilities ought to be accommodated
>>>    and proposes specific design patterns to achieve both classification
>>>    and differentiated QoS treatment on both a flow and aggregate basis.
>>>    operate purely at the network layer, providing the primitives needed
>>>    which can only be assessed and controlled at the application layer or
>>>    above.
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission

DaveO