Re: [icnrg] Last Call: draft-oran-icnrg-qosarch

Dirk,

> On 21 Jan 2020, at 19:47, Dirk Kutscher <ietf@dkutscher.net> wrote:
> 
> In Singapore, we mentioned that we would eventually like to publish draft-oran-icnrg-qosarch and after a discussion with the IRTF chair concluded that, given the nature of this document, the best way would be to treat it as a position paper and publish it as an Informational RFC without adopting it as an RG item.
> 
> The motivation is that this document, instead of specifying a specific architecture or mechanism, is rather illustrating a certain direction (that may or may not inform future specific QoS work in ICNRG).

I think it’s reasonable to publish this as a position paper, provided the RG is okay with that, but would it be possible to add a few words to the Introduction to explain why the ICN RG thinks this is best published as a position paper? (To be clear that the points in RFC 5743 Section 2.1 are explicitly addressed)

Also, the short title (“ICN QoS Architecture”) on each page can be read as perhaps implying a stronger status than intended. Is there space to change it to something like “Proposed ICN QoS Architecture” instead?

Colin

> We (Dave as the author, and Börje & myself as chairs) think that the draft is useful and mature enough so that we can move it towards publication, and I would therefore like to last-call it. Please read it and let us know if you think there are issues. The last call ends on February 7th, i.e., 2.5 weeks from today.
> 
> 
> https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/
> 
> 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.
> 
> Best regards,
> Dirk
> 
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg

-- 
Colin Perkins
https://csperkins.org/