Subject: [icnrg] Progressing my QoSArch position paper

From: "David R. Oran" <[email-masked]>
Date: Tue, 03 Dec 2019 10:29:17 -0500

I just submitted the update below. It reflects comments by a number of 
people and the discussion we had at the QoS side meetings in Singapore. 
Many thanks to those who commented, especially Thomas, Luca, Anil, 
Milan, and Prakash.

<Chair Hat off, purely Author hat on>

After discussion with Dirk & Börje, and with the IRTF chair, it seems 
we can move this through to publication without a formal adoption as an 
ICNRG RG work item. This to me is the appropriate course given the 
individual nature of the material and opinions contained in the 
document.

My personal view as author is that this is about as “cooked” as 
it’s going to be so I’d like to ask that we just do an ICNRG last 
call to assess people’s views on its readiness for IRTF review 
followed by publication.

Doing so will allow us to freeze this material and, as we discussed at 
the QoS side meetings, perhaps use it as reference/background material 
in the construction of a new RG-developed document on ICN QoS 
architecture.

I’ll leave to to Dirk and Börje to either confirm this course of 
action or suggest something different.

Many thanks,
DaveO

Forwarded message:

> From: [email-masked]
> To: Dave Oran <[email-masked]>, David Oran 
> <[email-masked]>
> Subject: New Version Notification for draft-oran-icnrg-qosarch-03.txt
> Date: Tue, 03 Dec 2019 07:20:29 -0800
>
> A new version of I-D, draft-oran-icnrg-qosarch-03.txt
> has been successfully submitted by Dave Oran and posted to the
> IETF repository.
>
> Name:		draft-oran-icnrg-qosarch
> Revision:	03
> Title:		Considerations in the development of a QoS Architecture for 
> CCNx-like ICN protocols
> Document date:	2019-12-03
> Group:		Individual Submission
> Pages:		25
> URL:            
> https://www.ietf.org/internet-drafts/draft-oran-icnrg-qosarch-03.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/
> Htmlized:       
> https://tools.ietf.org/html/draft-oran-icnrg-qosarch-03
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-oran-icnrg-qosarch
> Diff:           
> https://www.ietf.org/rfcdiff?url2=draft-oran-icnrg-qosarch-03
>
> 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
>    unfair 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.
>
>
>
>
> 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.
>
> The IETF Secretariat

---

From: "Dirk Kutscher" <[email-masked]>
Date: Thu, 05 Dec 2019 09:04:49 +0100

On 3 Dec 2019, at 16:29, David R. Oran wrote:

> we can move this through to publication without a formal adoption as 
> an ICNRG RG work item. This to me is the appropriate course given the 

> action or suggest something different.

Yes, I still think that’s a good way forward.

And, of course, this is just the beginning for QoS work in ICNRG. We are 
hoping that getting this published now would help people to start 
writing specific proposals, share experimentation results.

Best regards,
Dirk

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

---

From: Börje Ohlman <[email-masked]>
Date: Thu, 5 Dec 2019 09:39:31 +0100

I don’t have anything to add. I think this is the right way forward, but it is of course important what the ICNRG community at large thinks is the best way forward.

	Börje

> On 5 Dec 2019, at 09:04, Dirk Kutscher <[email-masked]> wrote:
> 
>> After discussion with Dirk & Börje, and with the IRTF chair, it seems we can move this through to publication without a formal adoption as an ICNRG RG work item. This to me is the appropriate course given the individual nature of the material and opinions contained in the document.
> 
>> I’ll leave to to Dirk and Börje to either confirm this course of action or suggest something different.
> 
> And, of course, this is just the beginning for QoS work in ICNRG. We are hoping that getting this published now would help people to start writing specific proposals, share experimentation results.
> 
> Best regards,
> Dirk
> 
> 
>> 
>> Many thanks,
>> DaveO
>> 
>> Forwarded message:
>> 
>>> To: Dave Oran <[email-masked]>, David Oran <[email-masked]>
>>> Title:		Considerations in the development of a QoS Architecture for CCNx-like ICN protocols
>>> URL:            https://www.ietf.org/internet-drafts/draft-oran-icnrg-qosarch-03.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/
>>> Htmlized:       https://tools.ietf.org/html/draft-oran-icnrg-qosarch-03
>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-oran-icnrg-qosarch
>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-oran-icnrg-qosarch-03
>>> 
>>> Abstract:
>>>   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