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

Colin Perkins <> Sun, 09 February 2020 23:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FDBF12007A for <>; Sun, 9 Feb 2020 15:17:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IQTOt1E03HN0 for <>; Sun, 9 Feb 2020 15:17:55 -0800 (PST)
Received: from ( [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DCEDD120071 for <>; Sun, 9 Feb 2020 15:17:54 -0800 (PST)
Received: from [] (port=37319 helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1j0vpo-0002Uu-Du; Sun, 09 Feb 2020 23:17:53 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Sun, 09 Feb 2020 23:17:49 +0000
Cc: ICNRG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Dirk Kutscher <>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <>
Subject: Re: [icnrg] Last Call: draft-oran-icnrg-qosarch
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 09 Feb 2020 23:17:57 -0000


> On 21 Jan 2020, at 19:47, Dirk Kutscher <> 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?


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

Colin Perkins