Re: [icnrg] Beach reading!
"Dirk Kutscher" <email@example.com> Mon, 12 August 2019 21:48 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE72120E62 for <firstname.lastname@example.org>; Mon, 12 Aug 2019 14:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ([22.214.171.124]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWkmBOYNov_N for <email@example.com>; Mon, 12 Aug 2019 14:48:52 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [126.96.36.199]) (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 CE2AC1215D8 for <firstname.lastname@example.org>; Mon, 12 Aug 2019 05:47:33 -0700 (PDT)
Received: from [192.168.1.69] ([188.8.131.52]) by mrelayeu.kundenserver.de (mreue107 [184.108.40.206]) with ESMTPSA (Nemesis) id 1MOiU5-1hed6g2NXL-00Q9Nv; Mon, 12 Aug 2019 14:47:17 +0200
From: "Dirk Kutscher" <email@example.com>
To: "David R. Oran" <firstname.lastname@example.org>
Cc: ICNRG <email@example.com>
Date: Mon, 12 Aug 2019 14:47:15 +0200
X-Mailer: MailMate (1.12.5r5635)
References: <firstname.lastname@example.org> <B33F9286-1E5E-4C8A-818B-B2BA3565113A@orandom.net>
Content-Type: multipart/alternative; boundary="=_MailMate_E9F4EBD8-7DBE-4E89-8A3A-DB714427B5C3_="
X-Provags-ID: V03:K1:pXR4paF3lHa8LQ5FaP+2DTQzyX+AzhHMIGF/OZlYyG9EQwC2WN4 Lp09kYro0WPtcYesAprhQNZtWp93s9kqFk2nxnibZ33oT2O52mnviXg7KxThwQBtvbX2A/L 1yXtt97Kr03je+YYbyAe6pKS7Mx60NVY5a3TQqxxEJMaWxz+odApdzvnyrHzubH4fj08J8w VOyJf2vQhLv64Zox3/iUQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:C7MghEqgjFQ=:+wIv+05OIm9gfddJG7kbiG IeZ98C+q5mDDPZovhUXDzHoq5z/THVU8Q48JeLYZY5x0NRGxT5osTgfvPgf10vtsTBIfp5nwk rx7R7EqQUijkgB0ZYWMKF3/4EgHsUISeQlB613H7UySZJT41/nmZVjf8NndhFJQgz60mvRQjJ ZsKAubwgMwMtMHTxiZdLJXwBmFd3M6MDN7tWQftoV77Qp5rEz/1dplpuitNEPfyqI+qG0hnva TLpVbuwd4fNrzjRU6LrVnVgGo3q4Ywv2+Z8rfs4ePVHsaB6qkeXRuCqDFI8ANMM26Ih7nY5+Z rgzeol9UbZbztzSWLQgRBzNIX17aiEL00VZRx3Cpaz4R6wFcMTtsEPmt1pudKF/JxnBoff7LO kvvQ20vHuCo4AEbhsFucjyGOkB3+uiOgiP2pw6rcr6i5q1XoOS7DcRNqTJePkoDDlwjvj4Al9 IeMoWJDan+NX2aUX2bYtVnMQnyEUryJ2+ta35ej9w5iskbkGOlMouBO3O33ePH6GpQB4SfAm3 MMe51h20sTAUOU6BKK5XqIL5AmhMoDdWPqaom4qMq1da0l/V8z1WXY51dbWCwd+I4G7kZRUFD DjtuPBtfhYY7WEVSLwOigIOFO7RSEhqptCjxUXXnvsc2HLvcnCbXJTs5atKbkU9L5v4QheQhy VhZY2N/DqJzXdnvogRdqFZ0ozJU8gZE+KLL8Hg+fdDiqJ0U+aLHSFcWmkqyA6JtnSQGafHbld 8y5TyNSVLqWd+efepBANGIq3y1Fi3Tl6lO2idiBFOTMB9VJfrOmFFau7S8o=
Subject: Re: [icnrg] Beach reading!
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Aug 2019 21:49:01 -0000
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: > 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@example.com >> To: firstname.lastname@example.org >> 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 >> I-D-Announce@ietf.org >> 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 > > _______________________________________________ > icnrg mailing list > email@example.com > https://www.irtf.org/mailman/listinfo/icnrg