Re: [icnrg] Comments on the recently posted draft-anilj-icnrg-dnc-qos-icn-01
Akbar Rahman <Akbar.Rahman@InterDigital.com> Thu, 19 September 2019 05:16 UTC
Return-Path: <Akbar.Rahman@InterDigital.com>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E8B12011E for <icnrg@ietfa.amsl.com>; Wed, 18 Sep 2019 22:16:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=interdigital.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pPVOk5co0S9 for <icnrg@ietfa.amsl.com>; Wed, 18 Sep 2019 22:16:42 -0700 (PDT)
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730096.outbound.protection.outlook.com [40.107.73.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4637E12010E for <icnrg@irtf.org>; Wed, 18 Sep 2019 22:16:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zvwv80s+fZ4CCybyHw5THUN691DdprmOyYRo2lx8pvZyAiM+btlb8QtcU6n9slKU/wuVpi3m6UcSblmcqPjTKyThtmpBd/uf1X1qbdzD0MEauRmmtJXyvC/eQkAm9QvsUJilML/zvPCHumIyEUCULG8AEKQwfsrChoyL4OzKrb/56jw8LfbxgDpaYCy2VnQRpHu4egTcEfNHlH9IzhSo4eTFNS/uf+9PL2XlEN0/OkmhWV13czNrdR7U8qdHjVwim65cGb3cPv0wqbYX8HPfaN9Gi0PTmhxh7sOQl69d266vV2Lh64froE7oXGl1/arH1HZ6+qJ96PzfXWjgeeA5JA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Os/1jg3K+yKWuWdjLZfYyeCnwe6oJdczj18Cwpr0yM8=; b=a05V8xTS6Wb8+XyCKYoK6phf6qCnvBCHK9kFpHCIlkfzoDW/G4+RXS7PV/ez/s6Gl02e5xWZuxC4B23Wkxow2kWcrHAU5kfGwy/cz5wbfTfLlftsduKHppeWgg5ScACQBEVcT3G2jxf5jT958q2USPjWvqslIMoMRSyimyA9vu7fLDxj1SbxlIg/i7XWhfkbhmjvQu/D8egby1UkYMZZmid94fdY7BMFf1qUUnXV4HuxvGL5fbZaakcXhA2gOChPEYnzEaN3lucwQL7Vbq1/Wmm76VfrvU6J7OBQGBE4IeItQr9QurmPD9gz2xa5Io5LA6Jhld3nWJD6fi9bAgP++A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=interdigital.com; dmarc=pass action=none header.from=interdigital.com; dkim=pass header.d=interdigital.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interdigital.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Os/1jg3K+yKWuWdjLZfYyeCnwe6oJdczj18Cwpr0yM8=; b=2d4DWjQR+SPI8Cw5ECApkUxpOEa0z3COa1/sqonPaFShSHnXBILnCUQpiFraxzGrmkJcXL/HkoIvzwG0UDJzpaqMb3WWRYMxgfGANtjqf9/H+D7nWUtCyxSqr3vNCN+dTdVieerj8VuswweyfSDGsQWp9ZdXQKxmEZ4HJROVfnQ=
Received: from DM6PR10MB3418.namprd10.prod.outlook.com (20.179.164.87) by DM6PR10MB4250.namprd10.prod.outlook.com (10.141.184.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.20; Thu, 19 Sep 2019 05:16:38 +0000
Received: from DM6PR10MB3418.namprd10.prod.outlook.com ([fe80::e181:5c51:cedc:c37]) by DM6PR10MB3418.namprd10.prod.outlook.com ([fe80::e181:5c51:cedc:c37%6]) with mapi id 15.20.2284.009; Thu, 19 Sep 2019 05:16:38 +0000
From: Akbar Rahman <Akbar.Rahman@InterDigital.com>
To: "Oran, Dave" <daveoran@orandom.net>, "Suthar, Prakash" <psuthar@cisco.com>, "Jangam, Anil" <anjangam@cisco.com>, "Stolic, Milan" <mistolic@cisco.com>
CC: "icnrg@irtf.org" <icnrg@irtf.org>
Thread-Topic: [icnrg] Comments on the recently posted draft-anilj-icnrg-dnc-qos-icn-01
Thread-Index: AQHVa80AHe+htDy6eEGphC/W87lUhKcybUKw
Date: Thu, 19 Sep 2019 05:16:38 +0000
Message-ID: <DM6PR10MB3418618166521BC990CD7F4EE7890@DM6PR10MB3418.namprd10.prod.outlook.com>
References: <7FDA432C-62ED-4D54-9098-E72071ABA3A4@orandom.net>
In-Reply-To: <7FDA432C-62ED-4D54-9098-E72071ABA3A4@orandom.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Akbar.Rahman@InterDigital.com;
x-originating-ip: [70.30.5.3]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 72e5a24f-3521-47df-9043-08d73cc08cb3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM6PR10MB4250;
x-ms-traffictypediagnostic: DM6PR10MB4250:
x-ms-exchange-purlcount: 2
x-ld-processed: e351b779-f6d5-4e50-8568-80e922d180ae,ExtAddr
x-microsoft-antispam-prvs: <DM6PR10MB4250EBDD4212F5D0C660F705E7890@DM6PR10MB4250.namprd10.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:2657;
x-forefront-prvs: 016572D96D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(39850400004)(396003)(376002)(136003)(366004)(189003)(51914003)(199004)(37854004)(40134004)(229853002)(66556008)(64756008)(66476007)(33656002)(66946007)(81166006)(3846002)(790700001)(316002)(2906002)(186003)(256004)(6506007)(53546011)(25786009)(26005)(11346002)(606006)(102836004)(446003)(71200400001)(476003)(99286004)(6116002)(486006)(6246003)(5024004)(86362001)(76176011)(76116006)(14444005)(71190400001)(8936002)(110136005)(66574012)(7736002)(66446008)(6436002)(81156014)(7696005)(66066001)(8676002)(5660300002)(4326008)(478600001)(733005)(561944003)(74316002)(30864003)(14454004)(236005)(54896002)(6306002)(55016002)(9686003)(52536014)(966005)(85282002)(579004)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR10MB4250; H:DM6PR10MB3418.namprd10.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: InterDigital.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: DII4ml7KyggDOzRQ7sSCtpxvOspaP1ovb/MFR/sy9yBnO6JK8CESOLhUQlbJvJaKE5ZxXNEtdKMTg+Gq8oupo6FITDunvH08+nADypNesgMCjjRjKkA3TZN7aSE4vCDmnB9dOPWRHhMYVreV19VDzzaAk6wpjBlhptnIJW0yxK0es4Q3B8Ct2/CxrLzLUTpmNEIQDqgti0jLh2As1DwVNCatrT6KhRCgA+ZLC9wdhVH9EQ1wUjHbJeSM5/jxJqMTkFDViiz+oYxNChb2WBeClZtJXCwngazNpOlXLSsINKd0Ka6jbiVqYigcPz7os3m1LzyQZ50Lepaq7+mtNsS4DI8A7oUFv6t58SgMLJX+fnexX4WafOp1WrQYHqfaW9bXu7gZfUNwV/25JCxzmj5VBspaLFYek2MaOl/a+Uajcj0=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR10MB3418618166521BC990CD7F4EE7890DM6PR10MB3418namp_"
MIME-Version: 1.0
X-OriginatorOrg: interdigital.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 72e5a24f-3521-47df-9043-08d73cc08cb3
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2019 05:16:38.7110 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e351b779-f6d5-4e50-8568-80e922d180ae
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 00fSkzihmfdwtc7oej47Uhgn21gJS2CWXhcHR5Fin5PxC+ES7Nb0D8ZxN8z352FuTVaShRy+P67VJTsudbHH+mxK8hOJ8yALy+QXskbDBrM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB4250
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/56orBwyvAdm9Zy1p92gps6mu3RQ>
Subject: Re: [icnrg] Comments on the recently posted draft-anilj-icnrg-dnc-qos-icn-01
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: Thu, 19 Sep 2019 05:16:53 -0000
Hi Dave/Authors, I have a few additional comments on top of Dave’s extremely thorough review: 1. Overall – A very useful draft that helps advance the issue of how to deal with E2E QoS (especially the data path) appropriately in ICN 2. General – I was expecting some reference/comparison/lessons-learned with Hybrid-ICN. Do you think it would be worth adding such info? 3. Abstract – While it is true many ICN systems have been implemented as an IP overlay, there are also other key ICN systems that have been implemented as an Underlay (e.g. as per the Deployment Considerations draft). This key point should be clarified. 4. Section 1: does TOS stand for Type of Service (in any case some reference should be given)? 5. Section 3.1: "authors points to" -> "the authors point to" 6. Section 3.1: Suggest adding a reference for "PURSUIT architecture" 7. Section 3.2: Suggest adding the full spelling for FIB (i.e. Forwarding Information Base) 8. Section 3.2: Table 1 discusses the difference between Flow Classification and QoS Marker, which is to be described in Section 4. Will it flow better to move Table 1 from Section 3.2 to Section 4? 9. Section 5.1: "...would publish and the routing protocol would advertise only..." - Suggest rephrasing this sentence 10. Section 6: It may be helpful to give one or some examples of QoS Marker, especially when talking about Consumer Procedure and Forwarded Procedure. 11. Section 6: Does QoS Marker apply to content packets only, or also for Interest packets? In other words, is there any QoS issues related to forwarding Interest packets? 12. Section 8: Should also consider security requirements for Producer Procedure in Section 6.3? 13. Section 9: "Interests requests" -> "Interest requests" 14. Section 9: Appears that more investigation/experimentation is required before we can decide if applying QoS treatment to (1) both Interest and Data/Content packets is better than just applying QoS treatment to (2) only on the Data/Content path Best Regards, Akbar From: icnrg <icnrg-bounces@irtf.org> On Behalf Of David R. Oran Sent: Sunday, September 15, 2019 9:53 AM To: icnrg@irtf.org Cc: Suthar, Prakash <psuthar@cisco.com>; Jangam, Anil <anjangam@cisco.com>; Stolic, Milan <mistolic@cisco.com> Subject: [icnrg] Comments on the recently posted draft-anilj-icnrg-dnc-qos-icn-01 These are all with <chair hat off> Many thanks for the continued work on this. It helps a lot to inform our development of QoS capabilities for NDN and CCNx in ICNRG. I have three sorts of comments. First are general/architectural comments. These are directly below in the email. Second are detailed technical comments, some of which emerge directly from the architectural questions; others are about specifics of the proposed design. Third are some editorial comments, typos, and nits. The latter two sets are embedded in the copy of the draft itself, which I append to the message. General/Architectural comments I doubt you will be surprised by these comments, as I’ve made most of them multiple times on both the earlier version of this draft, and in general discussions at ICNRG. I do think they are important enough to keep repeating since they cut to the core of what a QoS design for NDN and CCNx should look like. They also relate closely to the material in the recent draft I posted: https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/ so reading that first will help folks (not just the authors) understand better where I’m coming from. Here you go: 1. The design couples flow classification and QoS treatment into a single mechanism, the QoS Marker. I think this is a quite serious mistake. I cannot find a single good reason do do this, because flow classification is a property of the named objects in the namespace and how they relate to each other, while QoS treatment is a property of a particular fetch operation by an individual consumer. The flow classification persists independent of who the consumers are and what they are doing. The QoS treatment for the same content object could differ substantially when fetched by different consumers. Combining these just seems wrong. 1. Placing the QoS marker (as currently defined) as part of the name is also a mistake in my view. It complicates name parsing and involves what I consider to be problematic changes to both PIT and CS data structures (and possibly the FIB as well). I give what I think are convincing arguments in the QoSArch draft for why QoS treatment should be entirely independent of names. For flow classification, the most important question is whether the flows are bound into the security envelope of the content object or not. The flow classification draft presents both approaches and arguments for and against each. Your draft doesn’t seem to capture these issues in a way that adds to the understanding or informs the tradeoffs. It could be that both mechanisms of flow classification might be needed. By being clear about what is bound securely to a name, what is hierarchically decomposable (if you need flows and sub flows) and what can be aggregated by routers seems a key architectural decision that you can’t defer to some later detailed design discussion by defining QoS markers the way you do. 1. Much of the draft tries to make a distinction between “routable name prefixes” and “non routable name components”. No such distinction exists in either the semantics of CCNx or NDN names, or in their encoding. A deep feature of both designs is the notion that something is routable if it, or a prefix thereof, has a FIB entry. Period. The namespace designer does not have to pre-determine what part of the name is no longer useful for routing and specify it differently. Going with a QoS Marker approach with the marker part of the name introduces some pretty deep changes (at least as I see it) and will cause QoS-related things to permeate lots of parts of the design unrelated to QoS, such as name parsing, PIT structure, etc. Technical and Editorial Comments [I have snipped out parts of the draft I have no comments on, including the page break filigree and other artifacts of the .txt rendering]. My comments are all preceded by <do> and terminated with </do>. QoS Treatments in ICN using Disaggregated Name Components draft-anilj-icnrg-dnc-qos-icn-01 Abstract Mechanisms for specifying and implementing end-to-end Quality of service (QoS) treatments in Information-Centric Networks (ICN) has not been explored so far. There has been some work towards implementing QoS in ICN; however, the discussions are mainly centered around strategies used in efficient forwarding of Interest packets. Moreover, as ICN has been tested mainly as an IP overlay, it's QoS is <do>s/it’s/its/ </do> still governed by the IP QoS framework and there is a need for implementing QoS in ICN natively. This document describes mechanisms to classify and provide associated "name-based" extensions to identify QoS within the framework of ICN's core design principles. The name-based design provides a mechanism to carry QoS information and implement the treatments as ICN packets travel across different routers in the ICN network. Detailed discussion is provided for QoS specific procedures in each of the ICN network elements i.e. consumer, producer and forwarder. 1. Introduction Information Centric Networking (ICN) is rapidly emerging as an alternative networking mechanism for the TCP/IP based host-centric networking paradigm. Use cases of video conferencing [MPVCICN] and real-time streaming [NDNRTC] signify the value of ICN architecture and have been studied in detail. Also, a number of studies on routing of Interest and flow classification [ICNFLOW] have been published; however, relatively less work has been done on end-to-end quality of service (QoS) architecture for ICN. QoS is important to deliver preferential service to a variety of traffic flows resulting into better user experience. Evaluation and study of prior work done <do> s/into/in a/ </do> in this area is provided in Section 3. The current QoS implementation is based on either Layer-3 TOS or DiffServ, which is applicable only for ICN as an overlay. The QoS mechanisms described in this draft are applicable to the native ICN architecture. A detailed discussion related to the design of name-based QoS encoding, which is in line with ICN's fundamental design principles. <do>This last sentence is not a sentence - no verb</do> 1. Prior Work and Motivation 3.1. Prioritization of Interest Packets Among the work related to the quality of service (QoS) requirements in ICN network, larger emphasis is given to an optimized and efficient routing of Interest packets towards its content. M.F. Al-Naday et.al. in [NADAY] argues that information awareness of ICN network would help build scalable QoS model. In the context of CCN/NDN network design, authors points to the possibility of using <do> s/authors points/the authors point/ >/do> the QoS aware name prefixes, with potentially limiting the third parties (e.g. network operators) from defining an alternative QoS enforcement mechanisms. Moreover, the QoS solution is developed around the PURSUIT architecture, which may not be applicable to CCN/ NDN. Weibo Chu et.al. in [WEIBO] present a QoS model for ICN network based on the popularity ranking of the content and its placement/location in the network. They present a classification of the content into three categories - locally cached, remotely cached, and uncached contents, hence the network delay is modeled as a function of the distance of the content from the requester. Essentially, the QoS problem is seen in the perspective of faster routing of Interest request towards its content. In [XINGWEI] authors present a QoS mechanism, which is applicable to the routing of Interest requests in ICN network. The basis of the proposal is to decide the suitability of the forwarding link to make the process more energy efficient. They use the same Data forwarding algorithm specified in the original NDN design [JACOBSON]. In [CHRISTOS] Christos et.al. argue about a need for a differentiated routing and forwarding mechanisms based on not only the name of the content but also specifying the nature of the traffic. They further emphasize that this differentiation is better handled at the network level rather than leaving it for the upper layer. In all above use cases, the QoS related discussions are mainly focused on the forwarding of the Interest requests. It assumes that Data packets are forwarded in downstream direction according to the pending Interest table (PIT). There is little or no discussions provided about how preferential treatment can be implemented and enforced in the Data packet path. <do>The hop-by-hop interest shaper paper (Wang, Yaogong and Rozhnova, Natalya and Narayanan, Ashok and Oran, David and Rhee, Injong: An Improved Hop-by-hop Interest Shaper for Congestion Control in Named Data Networking, ACM ICN 2013) in fact shows how by shaping interests, the returning data packets are controlled and shaped, hence there is work on how if you have preferential treatment of Interests, preferential treatment of the returning data is achieved automatically </do> 3.2. Flow Classification in ICN Flow classification [ICNFLOW] describe the methods for classification of data flows in ICN. The method called equivalence class component count (EC3), uses a predefined number of name components of the <do> the count is not “predefined”. It is set by the producer when it creates the data packet containing the corresponding content object (not necessarily when the content object itself is created). It can also be included in an Interest and set by the consumer (or aggregated by a forwarder) which is by no means “predefined” either. </do> content name forming an equivalence class. While approach has the flexibility in re-grouping of components in aggregating the flows, it suffers from an inconsistent interpretation due to implicit binding of the equivalence class into the content namespace. In the second <do> I don’t understand what you’re saying here. What is inconsistent about the interpretation? By your logic, any flow aggregation would introduce inconsistencies since the aggregation is done by an element that is not in charge of the namespace. </do> method called equivalence class name component type (ECNCT), the flow classification information is directly embedded in the hierarchical content name. This paves the way to achieve implicit aggregation of <do>It seems you I and don’t have the same definition of “aggregation”. By my definition, aggregation means mixing multiple, possibly unrelated, flows together when maintaining flow state (and when enqueuing/dequeing packets for transmission). Using my definition ECNT does not do any implicit aggregation. It may permit hierarchical flow decomposition, but that’s something entirely different. </do> data flows analogous to the prefix-based aggregation of content names in FIB table. At the forwarder level, a flow table is implemented to store the equivalence classes and is used to perform the flow classification decisions. <do>this part I mostly agree with, however there are may ways to realize a “flow table”, some of which use an independent data structure with per-flow entries, while others do not (e.g. SFQ) </do> While both the schemes provide data flow classification in ICN, they are not sufficient for implementing a preferential service treatment in the network. Table 1 provide a summary of important differences between the flow classification and QoS treament implementation. <do> s/treament/treatment/ </do> <do> The above statement, while true, gives the impression that there is some deficiency in the flow classification design of EC3 or ECNT that needs to be remedied. That is not so, as if you adopt an architecture that cleanly separates flow classification from QoS treatment there is nothing missing. QoS treatment is handled completely separately. To elaborate on this, consider IntServ for IP. In Intserv, realized by RSVP, the machinery for specifying flows (the FLOWSPEC) is completely independent from the machinery for specifying QoS treatment (the TSPEC). I’ll also point out that flow classification can be extremely useful even in the absence of any QoS machinery, just to get flow fairness in your congestion control. By having an independent way to specify equivalence classes, that information can be used as input to the hashing scheme that drives a stochastic fair queuing (SFQ) algorithm. </do> +---+-------------------------------+-------------------------------+ | # | Flow Classifier | QoS Marker | +---+-------------------------------+-------------------------------+ | 1 | Identify the type of data | Identify the QoS treatment | | | flow | | | 2 | Set by the producer | Set by the consumer | | 3 | Immutable for the lifetime of | Can be modified in the | | | Interest | network | | 4 | Part of the routable content | Non-routable part of the | | | name | content name | +---+-------------------------------+-------------------------------+ Table 1: Difference between Flow Class and QoS Marker <do>I find this table very hard to swallow, since it tries to compare QoS marker with flow classifier, when architecturally flow classifier neither needs to (nor in my opinion should) have QoS treatment functions. Even line 1 has problems, since in your design the QoS marker both identifies the type of data flow and its treatment. In line 3, if you use EC3 as the classifier, it is not immutable for the lifetime of an interest and can in fact be aggregated/de-aggregated hop-by-hop. Line 4 is similarly misguided, both for the architectural reasons in my general comment (3) above and because you seem to be prohibiting QoS-sensitive routing by saying the QoS marker can only appear in a “non-routable” part of the content name. </do> By design, the data flow classification described in ECNCT is set by the producer at the time of registration of the content name and hence it is immutable for the life time of the content. Also, flow classification is encoded as part of routable name and therefore it has direct effect on both, PIT and FIB matching. <do> no, it has no effect on PIT matching in CCNx, since in CCNx uses only exact match. NDN used to only have prefix match, but now has switched primarily to exact match, with prefix match an option that can be requested by a consumer who needs it to invoke NDN’s content discovery mechanisms. </do> Since flow classification mechanisms are initiated or triggered at the producer, they lack to convey consumer's or application's context in deciding the traffic treatment in the network for individual data flows. <do> yes, and this is by design </do> 1. QoS Marker Encoding Choices In ICN protocols like CCNx, the ability to mutate the protocol metadata is directly controlled by whether it is placed inside the security envelop or outside. Likewise, for the encoding of the protocol metadata, such as QoS marker, two design choices are possible. o In first choice, encoding of QoS marker inside content name (in both Interest and content object) makes it immutable as it is inside an authentication signature and routers along a path cannot change it. <do>not only is it immutable, but it prohibits different consumers from requesting different treatments for the same data. Each possible QoS treatment a consumer might want would require a separate hashed and signed copy of the data. This seems somewhere between a serious mistake and a total non-starter. </do> o In the second choice, we define a mandatory hop-by-hop header to be able to change the QoS marker over time. <do>why does it have to be mandatory? I can’t see any reason to do that whether you mean just mandatory to implement, or mandatory to include in the packet.</do> While QoS mutability can be a useful feature, it can potentially suffer from an inconsistent end-to-end QoS treatment handling as each router can potentially change the QoS marking based on per hop traffic conditions. <do>some (me included) would say this is a feature, not something you suffer from. In fact, Diffserv supports both dropping and remarking. The problem with Diffserv here is that there is only one tiny QoS field in the packet, which means that if you remark you lose the original state. Your QoS marker scheme appears to suffer from the same deficiency. There is no reason at all to replicate this limitation for ICN. We could easily allow two QoS treatment TLVs, one for the original requested treatment and another mutated by routers to encode the active treatment, so that the original intent can be preserved end-to-end and also recovered by routers at boundaries between places that have remarked. Even better might be a QoS treatment stack where the remarking could be pushed/popped at boundaries that reshape/police packets. You in fact suggest this might be a good idea for further study later in the document. It would be better to either discuss it here, or not raise the bogie-man of “inconsistency” here. </do> On the other hand, the optional content name field in the content object makes it a nameless object. As an example, the nameless content objects are used inside a Manifest. So, one could put a QoS marking in an Interest name (to be used inside manifest), but it would not be used in the content object. It is for further study to find an encoding scheme to put QoS marker in content name of a nameless content object. <do> this last sentence seems to be self-contradictory. How can you put something in the name of a nameless object? </do> From routing and forwarding perspective, all name components are routable, in the sense that if they are in a FIB they will be <do> s/are routable/are potentially routable/ </do> matched. In case of name-based QoS marking, we can assume that router publishes only the name prefixes, exclusive of QoS markers. <do>Why? See my comment above about QoS-sensitive routing. Also, it’s the producer that publishes name prefixes, not routers. Routers only propagate them using the routing protocol </do> That said, globally routable FIBs would likely only have general name components. In summary, we have following options to design the QoS marking scheme based on. o Define a mandatory hop-by-hop header to be able to change the QoS over time i.e. hop-by-hop. <do>again, why mandatory? </do> o Encode QoS marker as a distinguished field inside a content object, but not part of the content name. <do> covered by the hash and the signature, right? Just need to be clear here, since it means is a given piece of content needs different QoS markers for different purposes, you need multiple copies of the data. If outside, then perhaps you shouldn’t say it’s “inside” the content object </do> o Find a way to make it work with nameless objects to be able to put it inside a name. <do>this isn’t very satisfying… especially as the previous bullet would contradict it. </do> In rest of the document, we discuss the design name-based encoding of QoS marker. <do> s/the design name-based/the design of name-based/ </do> 1. Name based QoS Marking Producer decides the classification of the data flow packets; <do> s/Producer/The producer/ <do> however, it is consumer's prerogative what QoS treatment is actually provided to them by the network. Consumer application itself or the network on behalf of consumer, can perform the QoS marking in the Interest messages. <do> this statement comports with my opinions of who is responsible for what, but seems to contradict what you say earlier about QoS markers being inside content objects, or part of their name. </do> Following factors govern the type of QoS markers we may require. o Consumer's subscription: The type of service user subscribes with the service provider e.g. subscription with high-speed data plan vs. low-speed data plan. o Service type: The type of service or the application consumer is running. As a reference, we may refer to service classes as described in RFC4594<see%20section%202.0>. <do>I think we need much finer granularity than this. Even a single application or service may need many different QoS treatments for different pieces of data. In fact, the two things cited may be better understood as policies that govern which QoS treatments are permissible under what circumstances, rather than the guiding source of what QoS treatments one needs to define. </do> 5.1. QoS Marker in Content Name Supporting the ICN design principles, the QoS marking is encoded in the content name field. Prior to their consumption, as both content and the content name are published by the content producer, it is important to make distinction between the content name and the QoS marker. As shown in Figure 1, there is a logical separation between the content name and the QoS marker. <do> this seems to be a physical and syntactical separation and not just a logical separation. </do> To support the consumer driven ICN design, QoS marker is encoded as non-routable part of the content name and hence is editable. To support the content matching algorithm at PIT and prefix matching algorithm at FIB, QoS marker is added at the end of the content name. <do> which means you can’t do exact match in the PIT anymore? How can you tell if the QoS marker is present or not so you can decide whether to strip it? You talk later about interest aggregation, which further complicates this whole approach. </do> +------------+------------+------------+-------------+-------------+ | Content | Content | Content | QoS | QoS | | Name comp-1| Name comp-2| Name comp-3| Name comp-1 | Name comp-2 | | | | | | | +------------+------------+------------+-------------+-------------+ |<---------Routable name comp--------->|<--Non-routable name comp->| Figure 1: Disaggregate Content and QoS Name Components The non-routable name component design of QoS marker allows consumer to add the QoS marking to the Interest message. The reasoning behind making it non-routable is that it does not affect the forwarder's name or prefix matching process directly; however, it can influence FIB's selection of forwarding faces the Interest packet is forwarded to. This allows for an implementation of QoS-aware forwarding strategy for both Interest and Data packets. <do>I certainly agree that having something that can be added by the consumer to an Interest and mutated by the forwarders is necessary, but why on earth put it in the name? </do> Finally, the idea of routable vs non-routable is that in general we believe that as QoS marker is the consumer-initiated activity and content producer (a.k.a. publisher) would publish and the routing protocol would advertise only the general name segments (i.e. content-name without any QoS marker in it) and thus be updated in a FIB entry. <do>If not “published” by the producer, then how do you do flow classification? This appears to be inconsistent in what you say earlier in the document. </do> 5.2. Name-based QoS Marker Scheme Figure 1 shows a reference model for name component-based QoS marker scheme. The number of QoS name components required shall depend on <do> s/shall depend/depends/ </do> the type of QoS encoding uses as well as the total number of markers required. QoS marker design can either be hierarchical or based on a flat naming scheme. The exact requirements and design specification of QoS marker is subject of further study. While exact specification of QoS marking are being studied, following are the potential mechanisms that can used for encoding of QoS marking into content name: o Using the path parameters addition to HTTP URI RFC3986<see%0A%20%20%20%20%20%20section%203.3>. We provide a summary of path parameter below from [RFC3986]. The path component contains data organized in hierarchical form serves to identify a resource within the scope of the URI's scheme and its naming authority. A path consists of a sequence of path segments separated by a slash ("/") character, which indicate hierarchy. A path parameter, part of a path segment that occurs after its name, control the representations of resource. A reserved characters often allowed in a path segment to delimit scheme-specific or dereference-handler-specific subcomponents. For example, the semicolon (";") and equals ("=") reserved characters are often used to delimit parameters and parameter values applicable to that segment. The semicolon ';' delimits the parameters i.e. anything in a path segment that comes after a ';' is treated as a new parameter. The '=' separate parameter names from their values i.e. anything that is specified after '=' sign is treated as parameter value. A parameter may have multiple values separated by a ',' symbol. Few examples of path parameter are shown below. * /content/name;param=val1 - Content name with single path param with single value * /content/name;param1=val1;param2=val1 - Content name with two path params * /content/name;param1=val1,val2 - Content name with single path param with two value <do> are you saying a CCNx forwarder actually has to parse all this rather than just doing tokenized match on name components? Do you think this can be done fast in the Interest forwarding path? (I don’t). </do> o Using the 'application payload name segments' approach defined in CCNX CCNXMESSAGES<see%20section-3.6.1.1>. The exact form and structure of QoS marking are being developed and more details shall be provided in next revision. <do>it may be worthwhile to have ICNRG give feedback on whether the group believes we should go down the path of putting QoS treatments in CCNx names before working on (and registering with IANA!) these components. I’ll also point out that if we go this way, they should not be application payload name segments, since they hopefully will not be application-specific, but rather globally agreed traffic treatments ala RFC4594 and registered as such in a separate registry with IANA. </do> 1. Network Procedures An important takeaway of implementing QoS is effective management of network resources such as, link capacity, bandwidth, and memory. ICN <do>well, this may seem pedantic, but you need effective management of network resources whether or not you provide QoS features. </do> follows a pull-based or a receiver driven design, which directly influences the load on to the network. Network based policy <do> Any scheme that transmits packets influences the load on the network. What are you trying to say here? What is special about the pull model? I indeed think its special, and I say how, but you don’t seem to reflect this in how QoS markers are intended to work. </do> configuration decides how the Interest and Data traffic is carried optimally, and producers, depending on where the content is, responds <do>optimality is nice, but I suspect it can’t be achieved via network policy configuration (alone). </do> to the requests from the consumers. With introduction of QoS marking in the Interest packet, important changes in the behavior of each of these network elements are discussed. 6.1. Consumer Procedure Consumer sends out the Interest packet into the network adding the QoS marker as per its service subscription and/or quality requirements. Consumer does QoS marking and adds it as non-routable name component, as shown in Figure 1. Consumer, the initiator of the Interest is the most appropriate network entity to perform the QoS marking for the following reasons: o ICN fundamentally is a pull-based, consumer driven design and consumer directly influences the resource allocation in the network in terms of timing and rate of Interest traffic. o Consumer is aware of the context of the application initiating the Interest. For instance, an application starting a simple video download compared to initiating a video conferencing. o Consumer at least partially in control of the traffic paths in both directions [MIRCC]. As an alternative to consumer adding the QoS marker in the Interest, the network (i.e. forwarder) can be allowed to amend the content name with the QoS marker. It should be possible since QoS marker is encoded as a non-routable component of the content name. <do>It’s not possible unless you change the rules for exact match in the PIT. </do> The network shall add the QoS marker based on the information such as, user's <do> s/shall add/adds/ </do> service or subscription authorization. In this context, an immediate forwarder (a.k.a. default gateway) would be the appropriate network node to perform this marking. <do> this is a small point, but in the ISP customer environment, the first hop router is rarely the one that would do the marking, since it isn’t controlled by the ISP (e.g. home router). It would usually be the PE router owned by the provider. If the consumer’s router (or the consumer for that matter) does mark, then it’s the PE router that’s the one likely to remark. </do>. Following aspects need more discussion: o Should network be allowed to add QoS marker in non-routable component of content name or should it add as a separate field of the Interest packets. <do>this is the very first time you bring up the possibility of not putting the QoS marker in the name. At this point it makes things pretty confusing as to what you are proposing in the design. </do> o Once QoS marker is added and Interest is admitted into the network should network be allowed to modify the QoS marker. o Since QoS markings are explicit, should the QoS marker be aware of consumer's subscription and make the relationship between the two explicit. <do>How would it be aware? This tangles up with client authentication, which seems orthogonal </do> 6.2. Forwarder Procedure ICN forwarder, in addition to preserving the Interest state into PIT table (mapping between content name and the interface it receives the Interest on), now also preserves the state of QoS marker against the interface. In a representative domain, the PIT structure is enhanced by adding a new column to save the state of QoS marker. This forms a 3-tuple information set comprising content name, interface, and QoS marker. <do> we’ve talked about this a number of times already. If you make the marker a third column on the PIT state you get data duplication and possibly an explosion of PIT entries. It’s entirely adequate to associate the QoS marker/treatment only with the interface the interest was received on. </do> Unlike PIT, there is no change in the structure of FIB table; however, forwarder forwards to the upstream ICN router both content name and QoS marker, as they are received from its predecessor. <do>unless you do QoS routing, in which case QoS treatments might be associated with a FIB entry. </do> With enhanced QoS-aware content name design, forwarder performs the content store (CS) lookup only using routable name component. <do>this seems wrong. what if there are name components that aren’t “routable” in the sense you use the word, but aren’t the QoS marker? In any event, some designs have a merged PIT and CS, so having different rules for lookups in the two would be highly problematic for them. </do> It is possible that a forwarder implementation may choose to understand name components types and do special things based on it. Conversely, the PIT aggregation logic uses both content name and QoS marker in PIT lookup, which makes it a QoS-aware Interest aggregation. Section 7.1 provide more details about new PIT design and related procedures. While there are no changes in the FIB table, the conventional name prefix based multipath forwarding path selection of forwarder can use the QoS marker to make the QoS-aware forwarding decision. For example, QoS marking can be used to select a low latency interface over a high latency interface or it can be used to select a high bandwidth path over a low bandwidth path or vice versa. <do>I don’t see how you do this if you don’t have some property in the FIB entry that tells you. </do>. The following aspects of QoS-aware forwarder design need more attention: o How mapping is done between QoS marking and the forwarding queue after the forwarding interface is selected. <do>while this is certainly true, this is one area where I don’t see any difference from IP or any other packet-oriented network architecture. You have a packet, you need to put it in a queue. Which queue does it go in and what happens to the other packets already in the queue? So, I suspect that the only part of this that belongs in an ICN QoS treatment design is what the treatments are and evidence to show that there are feasible queuing algorithms that can accomplish the intended semantics. </do> o From the perspective of per-hop-behavior (PHB), it is important to understand if remarking of QoS is allowed and if one marker is sufficient for it. One possibility is to preserve the original QoS marker added by consumer and have a running marker set by the intermediate forwarder in the network. <do>yes, this is one possibility. Another design question is whether the consumer is in control of whether the forwarder drops or remarks, and whether that decision is baked into the specification of each particular QoS treatment, or independently signaled in the Interest packet. There are arguments for either approach. </do> o In the context of QoS remarking by the network, it may also become important to let consumer know, what network is doing with their QoS marking. From the network behavior perspective, following are the possibilities: * QoS marking is preserved and obeyed in subsequent hop <do> here it think you mean “current hop”, not subsequent hop, since a forwarder can’t tell if the “subsequent” hop in the next forwarder is doing something or not. </do> * QoS marking is preserved but not obeyed * QoS marking is remarked and obeyed <do>I doubt any network operator would be willing to tell you if they actually obeyed your QoS treatment request. There’s also the problem of who gets to know which forwarder(s) ignored your request, or even what that means. For example, say you have a low-latency QoS treatment and you hit a forwarder not supporting priority queues, but whose interfaces are never more than 10% loaded. Is it obeying your QoS treatment or not? </do> <do> as an aside, years ago there was a major effort by All Morton and a pretty capable group from various Telcos in ITU to come up with a specification for how one could attribute QoS degradation to particular network elements in particular autonomous systems along a path. They did some very good work and had what some considered to be a technically sound solution. Of course they got laughed out of the room when they went back to their organizations and proposed that the customers having multi-AS paths could come try to blame one of the AS-es on the path. </do> 6.2.1. QoS and Multipath Forwarding QoS marking in the Interest packet does not change the multipath forwarding capability of ICN forwarders. In Section 7.2, more details are provided about specific QoS behavior related to multipath forwarding. 6.3. Producer Procedure Producer is aware of the disaggregation between routable name and the <do> s/Producer/The producer/ </do> non-routable QoS marker. It looks up the content in content store (CS) only using routable name component. An intermediate router acts in a similar manner. <do> see earlier comment about changing the exact match PIT and CS semantics </do> Depending on the what kind of QoS marking is done in the Interest packet, producer can have following response behaviors: o Producer may respond in a different manner with the Data packet to the consumer. <do> what does this mean, exactly? </do> o One such aspect of QoS aware response could be to provide the consumer information about how much distance (e.g. number of hops) Interest has travelled into the network before it is satisfied. <do> that’s not QoS-aware, that’s a basic forwarding feature. Also, since we do symmetric routing, you can do this just by re-purposing the hop-limit field to be a return hop count field in Data packets. I think I’ve proposed this in the past, and we could easily write a quick draft to add this to CCNx. </do> o QoS-aware response does not change the original requested content. 1. QoS-Aware Forwarder Design Towards supporting end-to-end QoS and handling of Interest and Data traffic throughout the network, important network procedures are discussed in Section 6. There are some important design changes in the way PIT maintains the pending Interests and the way forwarding decisions are made. This section discuss in detail each of the changes. 7.1. Enhanced PIT Design The new PIT design has added a new column to maintain the QoS marker received in the Interest packet. The enhancement in the PIT table and its behavior are applicable only specific to its Interest aggregation feature of multiple Interest packet received for the same content. <do> see earlier comment about PIT explosion. Again, this state needs to be stored in the incoming interface information, and hence is only one extra field in a part of the PIT that is O(#of incoming interfaces an Interest for this matching name has been received from) </do> +----+----------------+--------------------+--------------+ | | | | | | # | Interface Id | Content Name | QoS Marker | +---------------------------------------------------------+ | 1 | face-1 | /youtube/med/vid-1 | /qos-level-1 | +---------------------------------------------------------+ | 2 | face-2 | /youtube/med/vid-1 | /qos-level-2 | +---------------------------------------------------------+ | 3 | face-1 | /youtube/med/vid-1 | /qos-level-3 | +----+----------------+--------------------+--------------+ Figure 2: Enhanced PIT Design with QoS Marker <do> Why on earth would you store the name multiple times? </do> The scenarios emerging from the new QoS marking and new PIT design are discussed here. Three PIT entries are shown in Figure 2 to explain the new PIT design and its behavior. Notice that in the modified PIT design, content name always takes the higher precedence over the QoS marker in deciding the Interest aggregation. Having said this, following scenarios of Interest arrival at forwarder are possible: a. Two or more Interests with different content name, but with different QoS markers are received on two different interfaces. b. Two or more Interests with different content name, but with same QoS markers are received on two different interfaces. c. Two or more Interests with same content name and with same QoS markers are received on two different interfaces. d. Two or more Interests with same content name, but with different QoS markers are received on two different interfaces. e. Two or more Interests with same content name, but with different QoS markers are received on the same interface. <do> I think I’ve already made the comment on the -00 draft that this taxonomy is overly complicated and confusing </do> Scenarios (a) and (b), since both Interests are received with different content name, no PIT aggregation is required and Interest are forwarded if content is not found in CS. In case (c), since both content name and QoS marker are same, Interest is aggregated in PIT and second Interest is not forwarded. In scenarios (d) and (e), since Interests are received with same content name, the PIT aggregation decision is made based on the QoS marker. These two scenarios lead to a potential PIT scaling issue, which is discussed in Section 7.2. 7.2. Multiple Interest and PIT Scaling With two scenarios (d) and (e) in Section 7.1 forwarder forwards both the Interests to upstream router creating two PIT entries as shown in Figure 2 i.e. entries #1 and #3. This behavior violates the conventional PIT behavior; however, is essential to support the different QoS treatment. <do> no it isn’t, if you have a partial order defined over the space of QoS treatments. It’s a problem if all QoS treatments are considered unordered. </do> In order to support QoS-aware forwarding, the conventional PIT aggregation needs to be loosened up proportional to the number of QoS markers; in other words, the QoS treatments. Without this, upstream forwarder would not get an opportunity to obey each of the QoS treatments. The theoretical upper bound on the PIT scaling for given content will be equal to number of QoS markers. The impact on the PIT scaling depends on and can be mitigated by the following mechanisms: o By keeping the number of QoS markers limited o By keeping the QoS marker unique and avoiding the hierarchy or order among them. o In real-time case, the PIT may not hit the upper bound all the times i.e. not all QoS markers are utilized all the times on the same content name. <do> this is an important point. If we can demonstrate that for any given equivalence class in a namespace, the number of different QoS treatments that might be active at any given time is tightly bounded, that might be sufficient </do> o Using an optimization in multiple Interest handling, as discussed in Section 7.3 7.3. Handling PIT Scaling The PIT scaling issue described in Section 7.2 can be handled with an optimization discussed here. The forwarder can avoid forwarding the second/duplicate Interest if it receives it with a lower QoS marking than the one already pending in PIT. Thus, achieving the Interest aggregation based on the higher QoS marker for given content name. Conversely if the received Interest is with a higher QoS marking, then forwarder forwards the Interest and updates the pending PIT entry with higher QoS marking. Also, note that forwarder updates the PIT entry irrespective of the interface the higher QoS marked Interest is received on. <do> be careful here to have some mathematical rigor about what it means to be “higher”. </do> Notice that forwarding of Interest with higher QoS marker in spite of having an already pending with a lower QoS marker, is a breach of Interest aggregation at PIT in conventional terms; however, it is necessary to give an opportunity for upstream routers to provide appropriate QoS treatment to the higher priority Interest and the resulting Data traffic flow. These are the scenarios, which provide for a QoS-aware PIT design, Interest aggregation and forwarding in ICN router. 7.4. Data Delivery at PIT With QoS-aware Interest aggregation at PIT, more than one Interest are flowing in the network for the same content. With a higher probability of a priority treatment to the higher QoS marked Interest at each hop and with the possibility of multipath forwarding, it is highly likely that the Interest with higher QoS marking shall be satisfied faster than the Interest with lower QoS marking. <do> sorry, I don’t follow this. Some paths may be more loaded with high QoS treatment than others, and hence if you choose to send a lower marked Interest on the lightly loaded path it could very well be satisfied sooner. It might also hit a closer cache. </do> The Data packet arrival may satisfy all the PIT entries for the given content name irrespective of the QoS markers in Data packet. This is possible mainly because the content itself in Data packet does not change by different QoS marker in the Interest. Depending on whether forwarder implements a PIT scaling optimization, two scenarios of Data forwarding are possible: o Data packet to the downstream interface is forwarded with its original QoS marking recorded by the PIT. <do> yes, however this also determines how the data packet is queued on the downstream interface. </do> o Data packet to the downstream interface is forwarded with the higher QoS marking recorded by the PIT by virtue of PIT optimization. <do> no. I see no justification for this option. </do> With the PIT optimization described in Section 7.3, it is possible to satisfy a pending Interest with lower QoS marking with arrival of a Data packet having higher QoS marker. As a result, a user with lower QoS subscription may experience a better response time from the network. Note that this is a legitimate behavior, as ICN is fundamentally designed to optimize the network round-trip time providing better user experience. <do> while this might seem superficially true, there are, at least for some scenarios like adaptive video streaming, good reasons to intentionally delay or otherwise give lower service to requests issued with particular QoS treatments. This, one the other hand, is a longer discussion/explanation than is appropriate for these comments. </do> <do> However, we’ve now gotten to the end of the main content, and you haven’t talked about the interaction of QoS markers (or in my world, QoS treatments) with caching at all. Any spec that purports to show how QoS works for ICN needs to address not just link resources, but cache resources as well. In some circumstances (e.g. the constrained network scenarios discussed in https://datatracker.ietf.org/doc/draft-gundogan-icnrg-iotqos/) you need to specify the behavior of forwarder memory and forwarding CPU capacity as well. That’s a major missing piece for your work. </do> 1. Security Considerations ICN being name-based networking opens up new security and privacy considerations which have to be studied in the context of name-based QoS framework. Depending on where the QoS marker is encoded in the Interest, certain security attack scenarios against QoS treatment are possible. If the QoS marker located inside the security envelope, it can be read, but not changed. Conversely, if the QoS marker is placed outside of the security envelope, it can be added as hop-by-hop message header and, therefore, can be modified by the transit ICN forwarders; however, it also opens it to various attack scenarios. <do> and these are? Especially, are they new, amplifications of existing attacks, or inherent in the ability of any on-path element to most anything it likes? You also need to distinguish attacks mounted by consumers, those mounted by producers, those mounted by on-path forwarders, and those mounted by off-path elements. </do> Consumer procedure discussed in Section 6.1 and forwarder procedure discussed in Section 6.2 shall decide the security requirements related to implementing QoS treatments in ICN. 1. Summary This draft provides an architecture to implement end-to-end QoS treatments in ICN network using a name-based disaggregation of routable content name and non-routable, mutable QoS markers. The independence between content name and QoS marking makes their evolution easier and yet bounded to content name keeping with ICN principles. A new PIT design and a potential impact on PIT scaling is presented. An optimization to deal with the PIT scaling problem is discussed where a number of pending Interests requests in PIT for same content to be normalized around the highest QoS marking. Security requirements are dependent on whether QoS marker is encoded inside security envelop or outside of it. Consumer and forwarder procedure requirements shall also govern the security features. A detailed analysis and evaluation shall be performed, through prototype using [VICN] and/or simulation [NDNSIM], of the impact on PIT aggregation and effect of optimization. The details on design of a naming scheme for QoS marking in content name needs to be worked on. It is also necessary to test and measure the effectiveness of the QoS framework by deploying it using a multimedia streaming application. 1. Acknowledgements We thank all contributors, reviewers and the chairs for their valuable time in providing the comments and feedback, which has helped to improve this draft. We would like to thank Mark Mosco who <do> s/Mark Mosco/Marc Mosko/ </do> provided a useful feedback on proposed name-based encoding scheme and nameless content objects. 1. IANA Considerations This draft includes no request to IANA. <do> change this to “TBD” since once completed the document would undoubtedly have substantial actions needed by IANA </do> [End of comments] [Banner] [Banner] [Banner] This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.
- [icnrg] Comments on the recently posted draft-ani… David R. Oran
- Re: [icnrg] Comments on the recently posted draft… Akbar Rahman