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

"Dirk Kutscher" <ietf@dkutscher.net> Tue, 21 January 2020 19:47 UTC

Return-Path: <ietf@dkutscher.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 39AEA12006B for <icnrg@ietfa.amsl.com>; Tue, 21 Jan 2020 11:47:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jYhjkk8xHzmR for <icnrg@ietfa.amsl.com>; Tue, 21 Jan 2020 11:47:16 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C7112003F for <icnrg@irtf.org>; Tue, 21 Jan 2020 11:47:15 -0800 (PST)
Received: from [] ([]) by mrelayeu.kundenserver.de (mreue012 []) with ESMTPSA (Nemesis) id 1MNfgZ-1jHHvg1Ljf-00P5Rk for <icnrg@irtf.org>; Tue, 21 Jan 2020 20:47:11 +0100
From: Dirk Kutscher <ietf@dkutscher.net>
To: ICNRG <icnrg@irtf.org>
Date: Tue, 21 Jan 2020 20:47:06 +0100
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <E35749ED-CFB8-4352-BE66-724BC2C49B64@dkutscher.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"; markup="markdown"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:qcc8LeRhyj9aXSkqfxoODmtV+/qigP4nIfv+R0c3BUsWt+5WaSv a1GtVCxCQLfPznoDHb6QQTX4VsgTVQ2r7fa0jGB0TF+K290t7uzKomVvA7G1c70eJQVrcLk b5bvO0EK/JXbCbHA6dfDsfLUAI16ciH62ii5B5Eu/AHq1RMmGRVYlw1IxRZJuS/PGAUr0+r G+tfivbNE6n0Cj/6YJDlg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:xLMNncJPmK8=:r6ub3E1Tqi88mYrP66bPaM 2FeSRYMnCjIKYG4XyDQcrtVUkPMyh+JXyiM4mwSVjxYCSBzwXkhvBRXIU9JaM87WygBKFsrgX Y48M4xyf8ZkQp/WVq2gzmP40bcK/b+HcsIs4IeZFaeir1rIhzflo7foGqt1c+TI4ZzqNUZj+v lnbL24lQHPHoFMOnvihN/ytfKJUGZ2aa38iQ2lh8oA835++JHZ2Lri3xGvm3NldIQfGRJjKJ/ Y0J6p619HU5UuDVcHN0dQuqD/uanKhdotDu3Qefd9yKaSeI9rhr8OTtMdBnx/B1r5KYxF4r3q 8rxYmHLSojXHzEfEqxqLaRojOY2IPPU3ebqMdf0f1XmsWM9+jN66hB1T1C67ZXoUWAWVwp6bZ fuldwicli1QIpDxxOqqI6PwtbuMQM3MGHcK+LXalkSkfQJQyJ1RkHl9Zy9hHkLgcQQ6YZRVcU 28Myj5G7zfRK9xvaLhvHS5Fwm515ULgea9WqabHU/g1uZYJ3+VZD9H8cRqoTwinmhDdYdqQwl elQgKyfuZAk5pzOrvl0elSarRRcLSW7Lpu69m8OIlt8o3W1terC9pfZlme5t3FDclnsWW5doa pseFDh2AejT9HiLpnybqOPhCmba+3b1WJr+JbGTky+MWkgPKx28TXe4n2bKX02jpwIIbggiK4 Eu+ZUETKDCaO0cCqmACwF1Do/hMYVtK9Hv/gNVJPXLFWxVNYfgPPUl2igWUCXmSt5rdw/Ddl4 TiVBc/8oPnElpH0QXHSPPmNEOrejiEcA/1lGXfHE8aGR6+6FlWQyo7/SIkYPX7ymdcX5iHJ7B DzKrsFgYB8i87lOvc9VM+YI+eNali4w2rb06xacJ/ae3evF4msEE4obIs2TPDzNarIZWtm0K+ 9pBm2ul4bcTbIuQzpGc4BF1Z5whvWKQQ2LncJMBTc=
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/kCt3_5HYZP5HnJctFYSK-kItAnI>
Subject: [icnrg] Last Call: draft-oran-icnrg-qosarch
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2020 19:47:21 -0000

Hello ICNRG,

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

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.



    This is a position paper.  It documents the author's personal views
    on how Quality of Service (QoS) capabilities ought to be 
    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 

Best regards,