idnits 2.17.1 draft-ravi-icnrg-ccn-notification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 30 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 341: '...r, CCN forwarder MUST NOT cache the Co...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2016) is 2850 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'TBD' on line 312 == Unused Reference: '3' is defined on line 719, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 726, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 743, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-mosko-icnrg-ccnxmessages-00 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group R. Ravindran 3 Internet-Draft A. Chakraborti 4 Intended status: Informational S. Amin 5 Expires: January 8, 2017 Huawei Technologies 6 J. Chen 7 Winlab, Rutgers University 8 M. Mosko 9 I. Solis 10 PARC 11 July 7, 2016 13 Support for Notifications in CCN 14 draft-ravi-icnrg-ccn-notification-00 16 Abstract 18 This draft proposes a new packet primitive called Notification for 19 CCN. Notification is a PUSH primitive and can be unicast or 20 multicast to multiple listening points. Notifications do not expect 21 a Content Object response hence only requires the use of FIB state in 22 the CCN forwarder. Emulating Notification as a PULL has performance 23 and routing implications. The draft proposes a new fixed header 24 primitive called Notification and a CCN message encoding using 25 Content Object primitive to transport Notifications. These 26 discussions are presented in the context of CCNx1.0 [1] proposal. 27 The draft also provides discussions on various aspects related to 28 notification such as flow and congestion control, routing and 29 reliability considerations, and use case scenarios. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 8, 2017. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Notification Requirements in CCN . . . . . . . . . . . . . . 3 67 3. Current Approaches . . . . . . . . . . . . . . . . . . . . . 4 68 4. Proposed Notification Primitive in CCN . . . . . . . . . . . 5 69 5. Notification Message Encoding . . . . . . . . . . . . . . . . 5 70 6. Notification Processing . . . . . . . . . . . . . . . . . . . 8 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 8. Annex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8.1. Flow and Congestion Control . . . . . . . . . . . . . . . 9 74 8.1.1. Issues with Basic Notifications . . . . . . . . . . . 9 75 8.1.2. Flow and Congestion Control Mechanims . . . . . . . . 10 76 8.1.2.1. End-to-End Approaches . . . . . . . . . . . . . . 10 77 8.1.2.2. Hybrid Approaches . . . . . . . . . . . . . . . . 11 78 8.1.3. Receiver Reliability . . . . . . . . . . . . . . . . 13 79 8.2. Routing Notifications . . . . . . . . . . . . . . . . . . 14 80 8.3. Notification reliability . . . . . . . . . . . . . . . . 14 81 8.4. Use Case Scenarios . . . . . . . . . . . . . . . . . . . 15 82 8.4.1. Realizing PUB/SUB System . . . . . . . . . . . . . . 15 83 9. Informative References . . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 Notification is a PUSH primitive used in the Internet today by many 89 IoT and social applications. The nature of notifications varies with 90 the application scenario, ranging from being mission critical to one 91 that is best effort. Notifications can be unicast or multicast 92 depending on whether the notification service is aware of all the 93 consumers or not. A notification service is preceded by a consumer 94 subscribing to a specific event such as, subscription to hash-tag 95 feeds, health emergency notification service, or temperature sensor 96 reading from a room in a building; following this subscription the 97 service pushes notifications to consuming entities. It has to be 98 noted that certain IoT applications expects notification end-to-end 99 latency of few milliseconds [2]. Industrial IoT applications have 100 more stringent requirement in terms of QoS, timeliness, and 101 reliability of message delivery. Though we term it as a 102 Notification, this primitive can also be used for transactional 103 exchange between two points. 105 CCN optimizes networking around efficiently distributing already 106 published content which the consumers learn through mechanisms like 107 manifests containing the names of published content chunks and their 108 locations. Applications relying on notifications requires event 109 driven data to be pushed from multiple producers to multiple 110 subscribers for which the current Interest/Data primitive is 111 inefficient. This draft proposes to extend CCN's current primitives 112 set with a new notification primitive that can be processed in a new 113 way by the CCN forwarder to serve notification objectives. 114 Notification here implies a PUSH semantic that is available with IP 115 today and supported by other FIA architectures like MobilityFirst 116 [10] and XIA [11]. 118 2. Notification Requirements in CCN 120 General notification requirements have been discussed in CoAP's 121 Observe proposal [4] to push notifications from the server to the 122 clients. Here we discuss basic notification requirements from CCN's 123 network layer perspective. Other requirements related to 124 reliability, low latency, flow control can be engineered by the 125 application or through more network layer state once the following 126 requirements are met. 128 o Supporting PUSH Intent: CCN should provide efficient support for 129 PUSH, where application's intent is to PUSH content to listening 130 application without expecting any data in return. 132 o Multicast Support: CCN network should be able to handle multicast 133 notifications from a producer to multiple consumers. 135 o Security: Just as a content object in the context of Interest/Data 136 primitive provides data authentication and privacy, similar 137 features should also be offered by notification objects too. 139 o Routing/Forwarding Support: Name prefixes over which multicast 140 notifications are managed should be handled in a different manner 141 from the name prefixes over which Interest/Data primitive is used 142 for content distribution. This differentiation applies to the 143 control as well as the forwarding plane. 145 o Minimizing Processing: Notification processing in the forwarder 146 should be minimized considering the application's intent to PUSH 147 data to listening consumers. 149 3. Current Approaches 151 Recent CCN and NDN research [7][13] have studied the problem of 152 handling notifications and have proposed several solutions to handle 153 this. However these approaches do not meet the above set 154 requirements as they use the current Interest and Data primitive to 155 achieve notification objectives. These approaches are: 157 o Polling: This is a straight forward application of the Interest 158 and Data primitive, where consumers periodically checks the 159 producers for any new information. The efficiency of this 160 approach depends on the frequency of polling. In this case, very 161 low frequency may result in missing critical updates, and large 162 frequency could result in high PIT occupancy by such polling 163 Interests and overall higher traffic overhead. This scheme is 164 inefficient particularly for event driven and asynchronous 165 updates. 167 o Long lived Interests: As the name suggests, applications can issue 168 Interests set to a high lifetime to the producing nodes. 169 Considering the increasing social networking and IoT application 170 traffic, the number of such PIT Interests can be very large 171 occupying valuable resources hence inefficient. 173 o Interest overloading: Small notifications such as actuating 174 commands can be send by overloading the Interest primitive by 175 adding information as suffixes to the name or including signed 176 and/or encrypted data as a Interest payload [1]. As these 177 Interests are used as notifications, their lifetime is set to 178 zero. Overloading Interests to convey notifications may not be 179 desirable, as today the Interests are treated as a content request 180 primitive by forwarders incurring unnecessary PIT/CS incurring 181 unnecessary overhead. This also opens the possibility of new 182 attack vectors, such as the notifications can be blocked by 183 malicious consumers who may express Interests with the same name 184 (assuming names are easily derivable). Furthermore, this prevents 185 use of caching feature in the network, which is useful towards 186 data recovery. 188 o Interest Trigger: Another way to use Interest is to first notify 189 the consumers about a produced data, and then have the data pulled 190 by the consumers. This mechanism, in addition to the PIT 191 inefficiency, it also incurs additional round trip delay before 192 the produced data arrives at the listening consumer. 194 To summarize CCN and NDN operates on PULL primitive optimized for 195 content distribution applications. Emulating PUSH operation over 196 PULL has the following issues: 198 o It is a mismatch between an application's intent to PUSH data and 199 the PULL APIs currently available. 201 o Unless Interests are marked distinctly, overloading Interests with 202 notification data will undergo PIT/CS processing and are also 203 subjected to similar routing and forwarding policies as regular 204 Interests which is inefficient 206 o Another concern in treating PUSH as PULL is with respect to the 207 effect of local strategy layer routing policies, where the intent 208 to experiment with multiple faces to fetch content is not required 209 for notification messages. 211 This motivates the need for treating notifications as a separate 212 class of traffic which would allow a forwarder to apply the 213 appropriate routing and forwarding processing in the network. 215 4. Proposed Notification Primitive in CCN 217 Notification is a new type of packet hence can be subjected to 218 different processing logic by a forwarder. By definition, a 219 notification message is a PUSH primitive, hence is not subjected to 220 PIT/CS processing. This primitive can also be used by any other 221 transactional or content distribution application towards service 222 authentication or exchanging contextual information between end 223 points and the service. 225 5. Notification Message Encoding 227 The wire packet format for a Notification is shown in Fig. 1 and Fig. 228 2. Fig. 1 shows the Notification fixed header considering the 229 CCNx1.0 encoding, and Fig. 2 shows the format for the CCN 230 Notification message, which is used to transport the notification 231 data. We next discuss these two packet segments of the Notification 232 message. 234 1 2 3 235 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 236 +---------------+---------------+---------------+--------------+ 237 | Version | PacketType= | | 238 | | Notification | PacketLength | 239 +---------------+---------------+---------------+--------------+ 240 | HopLimit | Reserved | Flags | HeaderLength | 241 +---------------+---------------+---------------+--------------+ 242 / Optional Hop-by-hop header TLVs / 243 +---------------+---------------+---------------+--------------+ 244 / Content Object as Notification Message / 245 +---------------+---------------+---------------+--------------+ 247 Figure 1: CCN Notification fixed header 249 1 2 3 250 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 251 +---------------+---------------+---------------+--------------+ 252 |MessageType = Content Object | MessageLength | 253 +---------------+---------------+---------------+--------------+ 254 | Name TLV | 255 +---------------+---------------+---------------+--------------+ 256 | Optional MetaData TLVs | 257 +---------------+---------------+---------------+--------------+ 258 | Message Payload Type | Message Type Length | 259 +---------------+---------------+---------------+--------------+ 260 | Payload or Optional Content Object | 261 +---------------+---------------+---------------+--------------+ 262 / Optional CCNx ValidationAlgorithm TLV / 263 +---------------+---------------+---------------+--------------+ 264 / Optional CCNx ValidationPayload TLV (ValidationAlg required) / 265 +---------------+---------------+---------------+--------------+ 267 Figure 2: CCN Notification Message 269 Notification Fixed Header: The fields in the fixed header that have 270 new meaning in the context of notifications are discussed next, while 271 the other fields follow the definition in [1]. 273 o Packet Type: This new type code identifies that the packet is of 274 type Notification [TBD]. 276 o Optional Hop-by-hop header TLVs : Encodes any new hop-by-hop 277 headers relevant to notifications [TBD]. 279 CCN Notification message: The CCN Notification message is a Content 280 Object as in [1]. Notifications are always routed on the top level 281 Content Object (outer CO) name. Notification itself can be encoded 282 in two forms depending on the application requirement: 284 o Notification with single name: In this case the notification 285 contains a single content object. Here the producer generates 286 notification using the same name used by consumers on which they 287 listen on. 289 o Notification with two names: In this case the notification 290 contains a top level Content Object (outer CO), that encapsulates 291 another Content Object (inner CO). With an encapsulated Content 292 Object, the meaning is that notification producers and consumers 293 operate on different name-spaces requiring separate name-data 294 security binding. A good application of the encapsulation format 295 is a PUB/SUB service, where the consumer learns about the 296 notification service name offline, and the producer who is 297 decoupled from the consumer generates a new Content Object using 298 its own name and pushes the notification to the consumer. 300 The interpretation of the fields shown in Fig. 2 are as follows: 302 o MessageType : The CCN message type is of type Content Object. 304 o Name TLV : Name TLV in the Content Object is used to route the 305 Notification. 307 o Optional Metadata TLV: These TLVs carry metadata used to describe 308 the Notification payload. 310 o Message Payload Type: This is of type T_PAYLOADTYPE defined in 311 CCNx.1.0 or a new encapsulation type (T_ENCAP) that indicates the 312 presence of another encapsulated Content Object [TBD]. 314 o Optional Encapsulated Content Object: This is an optional 315 encapsulated Content Object newly defined for the Notification 316 primitive. The name in the encapsulated Content Object 317 corresponds to the producer's name-space, or anything else based 318 on the application logic. The rational for an encapsulated 319 Content Object was discussed earlier. 321 o Optional Security Validation data: The Content Object optionally 322 carries security validation payload as per CCNx1.0. 324 6. Notification Processing 326 The following steps are followed by a CCN forwarder to process the 327 Notification packet. 329 o Notification packet type is identified in the fixed header of a 330 CCN packet with a new type code. The Notification carries a 331 Content Object, whose name is used for routing. This name is 332 matched against the FIB entries to determine the next hop(s). 333 Novel strategy layer routing techniques catering to the 334 notification traffic can be applied here. 336 o CCN forwarder also processes the optional metadata associated with 337 the Notification meant for the network to help with the forwarding 338 strategy, for e.g., mission critical notifications can be given 339 priority over all other traffic. 341 o As mentioned earlier, CCN forwarder MUST NOT cache the Content 342 Objects in the notifications. 344 7. Security Considerations 346 The proposed processing logic of Notifications that bypass the 347 processing of PIT/CS has the following security implications: 349 Flow Balance : PIT state maintains the per-hop flow balance over all 350 the available faces by enforcing a simple rule, that is, one Content 351 Object is send over a face for a single Interest. Bypassing PIT 352 processing compromises this flow balancing property. For scenarios 353 where the notification traffic volume is not high such as for IoT 354 applications, the impact may not be significant. However, this may 355 not be the case considering the plethora of social networking and 356 emerging IoT applications in a general Internet scenario. This flow 357 balance tradeoff has to be understood considering an application's 358 intent to PUSH data and the latency introduced by processing such 359 traffic if a PULL primitive is used. Also PIT offers a natural 360 defense mechanism by throttling traffic at the network edge, 361 considering the provisioned PIT size, and bypassing it could 362 exacerbate DDOS attacks on producing end points. 364 Cache Poisoning: This draft doesn't recommend the caching of the 365 Content Object in the Notification payload, though doing so might 366 help in increasing the availability of notification information in 367 the network. A possible exception would be if the inner CO is a 368 nameless object [12]. as those can only be fetched from CS by hash We 369 leave this possibility of applying policy-based caching of 370 Notification Content Objects for future exploration. The 371 recommendation for not caching these Content objects is that, in a 372 regular Interest/Content Object exchange, content arrives at the 373 forwarder and is cached as a result of per-hop active Interest 374 expression. Unsolicited Content Objects, as in the case of the 375 Notification, violates this rule, which could be exploited by 376 malicious producers to generate DDOS attack against the cache 377 resource of a CCN infrastructure. 379 8. Annex 381 8.1. Flow and Congestion Control 383 8.1.1. Issues with Basic Notifications 385 As mentioned in the previous sections, one of the main issues with 386 notification is the flow and congestion control. One naive way to 387 solve this issue is the routers drop the packets from aggressive 388 flows. Flow-based fair queueing (and its variation stochastic 389 fairness queueing) maintain queues for flows (or the hash of flows) 390 and try to give a fair share to each flow (or a hash). Flows can be 391 classified by the prefixes in the ICN case. However, according to 392 [14], the overall network throughput will be affected when there are 393 multiple bottlenecks in the network. Therefore, [14] promotes an 394 end-to-end solution for congestion control. Flow balance is a key 395 requirement to an end-to-end (or end-driven) flow and congestion 396 control. In the case of CCN query/response, flow balance entails 397 that an Interest pulls at most one Data object from upstream. The 398 data consumer can therefore control the amount of traffic coming from 399 the data source(s) either it is a data provider or a cache in the 400 network. However, the basic notification does not follow the rule of 401 flow balance (each Subscription can result in more than one 402 Notifications disseminated in the network). In the absence of a 403 proper feedback mechanism to notify the data sender or the network 404 the available bandwidth and local resource the consumer has, the 405 sender can easily congest the bottleneck link of the receivers 406 (causing congestion collapse) and/or overflow the buffer on the 407 receiver side. In the later sections, we will describe the possible 408 congestion control mechanisms in ICN and how to deal with packet loss 409 when both congestion control and reliability are required. 411 However, the basic notification does not follow the rule of flow 412 balance (each Subscription can result in more than one Notifications 413 disseminated in the network). There is no way a receiver can notify 414 the data sender or the network the available bandwidth and local 415 resource it has. As a result, the sender can easily congest the 416 bottleneck link of the receivers (causing congestion collapse) and/or 417 overflow the buffer on the receiver side. 419 8.1.2. Flow and Congestion Control Mechanims 421 Here we discuss broad approaches towards achieving flow and 422 congestion control in CCN as applied to Notification traffic. Since 423 the forwarding logic of the Notification packets are quite similar to 424 that of IP multicast, existing multicast congestion control solutions 425 can be candidates to solve the flow/congestion control issue with 426 Notification. In addition we also summarize recent ICN research to 427 address this issue. 429 8.1.2.1. End-to-End Approaches 431 In the multicast communication, it is not scalable to have direct 432 receiver-to-sender feedback loop similar to TCP since this would 433 result in each receiver sending ACKs (or NACKs) to the data sender 434 and cause ACK (NACK) implosion. To address the ACK implosion issue, 435 two types of solutions have been proposed in multicast congestion 436 control, namely, sender-driven approaches and receiver-driven 437 approaches. 439 8.1.2.1.1. Sender-driven Multicast 441 In the first category, the sender controls the sending rate and to 442 ensure the network friendliness, the sender usually align the sending 443 rate to the slowest receiver. 445 To avoid the ACK implosion issue, TCP-Friendly Multicast Congestion 446 Control (TFMCC [15]) uses rate based solution. This solution uses 447 TCP-Friendly Rate Control (TFRC) to get a proper sending rate based 448 on the RTT between sender and each receiver. The sender only needs 449 to collect the RTTs periodically instead of per-packet ACKs. 450 Similarly, in ICN, the sender can create another channel (namespace) 451 to collect the RTT measurement from the receivers. However, due to 452 the dynamics on each path, it is difficult to calculate the proper 453 sending rate. 455 To address the rate calculation issue, pgmcc [16], a window-based 456 solution is proposed. It uses NACKs to detect the slowest receiver 457 (the ACKer). The ACKer sends an ACK back to the sender on receiving 458 each multicast packet. A feedback loop similar to TCP is formed 459 between the sender and the ACKer to control the sending rate. Since 460 the ACKer is the slowest receiver, the sender adapts its sending rate 461 to the available bandwidth of the slowest receiver, the solution can 462 therefore ensure the network friendliness. In the ICN case, the 463 receivers can send NACKs in the form of Notification packets through 464 another namespace, and the ACKer can also use the same mechanism to 465 send ACKs. 467 However, since the sender is always aligning the sending rate to the 468 slowest receiver to ensure the network friendliness, the performance 469 of the solutions can be dramatically affected by a very slow 470 receiver. 472 8.1.2.1.2. Receiver-driven Multicast 474 Unlike the sender-driven solutions, the receiver-driven solutions 475 [17] choose to use layered-multicast to satisfy heterogeneous 476 receivers. The sender first initiates several multicast groups 477 (namespaces in the case of ICN) with different sending rates. Each 478 receiver would choose to join a multicast group with the highest 479 sending rate that it can afford. The sender can also adapt the 480 sending rate of each multicast group according to the receiver 481 status. 483 These solutions can support applications like video streaming (with 484 layered codecs) efficiently. However, they also have some issues: 1) 485 they complicate the sender and receiver logic, especially for simple 486 applications like file transfer; and 2) the receivers are limited by 487 the sending rates initiated by the provider and would therefore 488 under-utilize the available bandwidth. 490 8.1.2.2. Hybrid Approaches 492 In this approach, flow balance of Notification is achieved by the 493 receivers notifying the network (rather than the sender or other 494 receivers) about the capacity it can receive. Here, we take 495 advantage of operating the Notification service through a receiver- 496 driven approach and get support from the network. 498 A solution based on this approach is proposed in [18], which we 499 summarize next. 501 To retain flow balance, the consumers in this solution send out one 502 subscription for only one next Notification instead of the original 503 logic (that receives all the Notifications). Similar to the flow and 504 congestion control in query/response, the receivers can now maintain 505 a congestion window to control the amount of traffic coming from 506 upstream. 508 Here, instead of maintaining a (name, outgoing face) pair in FIB (or 509 subscription table), the routers now adds a third field -- 510 accumulated count -- for each entry. The accumulated count is 511 increased by 1 on receiving such a subscription and decreased by 1 on 512 sending a Notification to that face. The routers should also 513 propagate the maximum accumulated count upstream till the 1st hop 514 router of the provider (or the rendezvous point in the network). The 515 subscribers sends a subscription for every successfully received 516 notification. Here we also assume that, the subscribers operate 517 based on the AIMD scheme. 519 If the dissemination of Notification follows a tree topology in the 520 network, we define the branching point of a receiver R (BP_R) as the 521 router closest to R which has another outgoing face that can receive 522 data faster than R. For receivers that has bandwidth/resources to 523 receive all the data from the provider, BP_R is the 1st hop router of 524 the provider (or the rendezvous point). 526 In this solution, we can prove that there is a feedback loop between 527 each receiver and its branching point. Therefore, when a receiver 528 maintains its congestion window size using AIMD, the traffic between 529 the branching point and the receiver is similar to TCP. It can get a 530 fair share at the bottleneck on the path, even if the bottleneck is 531 not directly under the branching point. In the multicast tree, the 532 solution can ensure the fairness with other (TCP-like) flows on each 533 branch. 535 The solution can thus allow the sender to send at an application- 536 efficient rate rather than being affected by the slowest receiver 537 like pgmcc [16]. 539 It is true that the solution requires more packets and more states in 540 the network compared to the basic notification solution, but the cost 541 is similar to (and smaller than) that of query/response. Since we 542 are using one notification per subscription pattern, the amount of 543 traffic overhead is the same as query/response. As for the states 544 stored in the router, the solution only requires 1 entry per prefix 545 per face, which is smaller than the query/response which requires 1 546 entry per packet per face. Therefore, the overhead of the solution 547 is acceptable in CCN. 549 8.1.2.2.1. Other Challenges 551 o Sender Rate Control: The sender in the solution does not have to 552 limit the sending rate to the slowest receiver to maintain network 553 friendliness. Therefore, the choice of sending rate is a tradeoff 554 between network traffic and session completion time. In the case 555 where the application does not require a certain sending rate 556 (like file transfer), the sender can align the sending rate to the 557 slowest receiver (similar to pgmcc) to minimize the repair 558 traffic, but at the cost of longer session completion time. He 559 can also send at the rate of the fastest receiver and try to get 560 peer repair in the network. This allows faster receivers finish 561 the session earlier but causing higher network traffic due to the 562 repair. An ACKer-based solution similar to pgmcc can be adopted 563 to allow the sender align the rate at a proportion of users (e.g., 564 top 30%). The sender can collect feedback (throughput, latency, 565 etc.) from all the receivers periodically and pick an ACKer 566 according to the proportion it desires. On receiving a 567 Notification packet, the ACKer would send an ACK just like TCP. 568 The sender can maintain a congestion window also like TCP. The 569 feedback loop between the sender and the ACKer can align the 570 sending rate at the ACKers's available bandwidth. 572 o Receiver Window Control: Slightly different from one-sender one- 573 receiver window control in TCP, the sending rate in the hybrid 574 approach is not controlled by any of the receivers. Receiving 575 intermittent packets can indicate both congestion (similar to TCP) 576 and not enough window size (since the sending rate is higher). In 577 the first case, the receiver should reduce the window size while 578 in the second case, the receiver should increase the window size. 579 An indication of congestion (e.g., Random Early Detection, RED) 580 should be provided directly from the network.The receivers with 581 available bandwidth higher than the sending rate would have too 582 large window size since it does not see any packet loss. Please 583 refer to [18] for a detailed solution on this issue. 585 8.1.3. Receiver Reliability 587 The receiver would miss packets when the available bandwidth/resource 588 of the receiver is lower than the sending rate of the Notification 589 provider. Some applications (like gaming and video conferencing) can 590 tolerant such kind of packet loss while the others (like file 591 transfer) cannot. Therefore, another module that ensures the 592 reliability is needed. However, reliability should be separated from 593 the flow and congestion control since it is not a universal 594 requirement. 596 With the solution described in the receiver-driver or the hybrid 597 approach, the slower consumers would receive intermittent packets 598 since the sending rate can be faster than their fair share. The 599 applications that require reliable transfer can query the missing 600 packets similar to the normal query/response. This also requires 601 that each content in the Notifications should have a unique Content 602 Name (or hash in the nameless scenario). The clients should also be 603 able to detect the missing packets either based on the sequence 604 number or based on a pre-acquired meta-file. Caching in CCN can be 605 leveraged to achieve availability and reliability. 607 The network can forward the requests (Interests) of the missing 608 packets towards the data provider, the other consumers and/or the in- 609 network cache to optimize the overall throughput of the consumers. 610 This solution is similar to Scalable Reliable Multicast (SRM [19]). 612 However, as mentioned in [20], solutions like SRM requires the 613 consumers communicate directly with each other and therefore lose the 614 privacy and trust. CCN can ensure the privacy since the providers 615 cannot get the information of the identity of the consumers. Trust 616 (data integrity) is also maintained with the signature in the Data 617 packets. 619 8.2. Routing Notifications 621 Appropriate routing policies should be employed to ensure reliable 622 forwarding of a notification to its one or many intended receivers. 623 The name in the notification identifies a host or a multicast service 624 being listened to by the multiple intended receivers. Two types of 625 routing strategies can be adopted to handle notifications, depending 626 on whether or not an explicit pub/sub state is maintained in the 627 forwarder. 629 o Stateless forwarding: In this case the notification only relies on 630 the CCN FIB state to route the notification. The FIB entries are 631 populated through a routing control plane, which distinguishes the 632 FIB states for the notification service from the content fetching 633 FIB entries. Through this logical separation, Notifications can 634 be routed by matching its name with the matching FIB policy in the 635 CCN forwarder, hence processed as notification multicast. 637 o Stateful forwarding: In this case, specific subscription state is 638 managed in the forwarder to aid notification delivery. This is 639 required to scale notifications at the same time apply 640 notification policies, such as filter notifications or to improve 641 notification reliability and efficiency to subscribing users [8]. 643 8.3. Notification reliability 645 This proposal doesn't provide any form of reliability. Reliability 646 can be realized by the specific application using the proposed 647 notification primitive, for instance using the following potential 648 approaches: 650 Caching: This proposal doesn't propose any form of caching. But 651 caching feature can be explored to improve notification reliability, 652 and this is a subject of future study. For instance, consumers, 653 which expect notifications and use external means (such as periodic 654 updates or by receiving manifests) to track notifications, can 655 recover the lost notifications using the PULL feature of CCN. 657 Notification Acknowledgment: If the producer maintains per-receiver 658 state, then the consumer can send back notification ACK or NACK to 659 the producer of having received or not received them. 661 8.4. Use Case Scenarios 663 Here we provide the discussions related to the use of Notification in 664 different scenarios. 666 8.4.1. Realizing PUB/SUB System 668 A PUB/SUB system provides a service infrastructure for subscribers to 669 request update on a set of topics of interest, and with multicast 670 publishers publishing content on those topics. A PUB/SUB system maps 671 the subscribers' interests to published contents and pushes them as 672 Notifications to the subscribers. A PUB/SUB system has many 673 requirements as discussed in [6] which include low latency, 674 reliability, fast recovery, scalability, security, minimizing false 675 (positive/negative) notifications. 677 Current IP based PUB/SUB systems suffer from interoperability 678 challenges because of application-defined naming approach and lack of 679 support of multicast in the data plane. The proposed Notification 680 primitive can be used to realize large scale PUB/SUB system, as it 681 unifies naming in the network layer and support for name-based 682 multicasting. 684 Depending on the routing strategy discussed earlier, two kind of PUB/ 685 SUB approaches can be realized : 1) Rendezvous style approach ; 2) 686 Distributed approach. Each of these approaches can use the 687 Notification primitive to implement their PUSH service. 689 In the Rendezvous style approach, a logically centralized service 690 maps subscriber's topic interest with the publisher's content and 691 pushes it as notifications. If stateless forwarding is used, the 692 routing entries contain specific application-ID's requesting a given 693 notification, to handle scalability, a group of these application can 694 share a multicast-ID reducing the state in the FIB. 696 In the Distributed approach, the CCN/NDN protocol is further enhanced 697 with new subscription primitive for the subscription interested 698 consumers. When a consumer explicitly susbcribes to a multicast 699 topic, its subscription request is forwarded to the upstream 700 forwarder which manages this state mapping between subscription names 701 to the downstream faces which has expressed interest for 702 Notifications being pushed under that prefix. An example of the 703 network layer based approach is the COPSS notification proposal [6]. 704 Here a PUB/SUB multi-cast state state, called the subscribers 705 interest table, is managed in the forwarders. When a Notification 706 arrives at a forwarder, the content descriptor in the notification is 707 matched to the PUB/SUB state in the forwarder to decide the faces 708 over which the Notification has to be forwarded. 710 9. Informative References 712 [1] CCN Wire format, CCNX1., "http://www.ietf.org/id/ 713 draft-mosko-icnrg-ccnxmessages-00.txt.", 2013. 715 [2] Osseiran, A., "Scenarios for 5G Mobile and Wireless 716 Communications: The Vision of the METIS Project.", IEEE 717 Communication Magazine , 2014. 719 [3] DNS Security Introduction and Requirements, DNS-SEC., 720 "http://www.ietf.org/rfc/rfc4033.txt.", 2005. 722 [4] Observing Resources in CoAp, observe., 723 "https://tools.ietf.org/html/draft-ietf-core-observe-16.", 724 2015. 726 [5] Cisco System Inc., CISCO., "Cisco visual networking index: 727 Global mobile data traffic forecast update.", 2009-2014. 729 [6] Chen, J., Arumaithurai, M., Jiao, L., Fu, X., and K. 730 Ramakrishnan, "COPS: An Efficient Content Oriented 731 Publish/Subscribe System.", ACM/IEEE Symposium on 732 Architectures for Networking and Communications Systems 733 (ANCS 2011) , 2011. 735 [7] Amadeo, M., Campolo, C., and A. Molinaro, "Internet of 736 Things via Named Data Networking: The Support of Push 737 Traffic", Network of the Future (NOF), 2014 International 738 Conference and Workshop on the , 2014. 740 [8] Francois et al, J., "CCN Traffic Optimization for IoT", 741 Proc. of NoF , 2013. 743 [9] CCNx Label Forwarding, CCNLF., "http://www.ccnx.org/pubs/ 744 ccnx-mosko-labelforwarding-01.txt.", 2013. 746 [10] NSF FIA project, MobilityFirst., 747 "http://www.nets-fia.net/", 2010. 749 [11] NSF FIA project, XIA., "https://www.cs.cmu.edu/~xia/", 750 2010. 752 [12] Mosko, M., "Nameless Objects.", IETF/ICNRG, Paris 753 Interim 2016, 2016. 755 [13] Shang, W., Bannis, A., Liang, T., and Z. Wang, "Named Data 756 Networking of Things.", IEEE IoTDI 2016, 2016. 758 [14] Floyd, S. and F. Kevin, "Promoting The Use of End-to-End 759 Congestion Control in The Internet.", IEEE ToN vol. 7(4), 760 pp. 458-472, 1999. 762 [15] Widmer, J. and M. Handley, "TCP-Friendly Multicast 763 Congestion Control (TFMCC): Protocol Specification.", IETF 764 RFC 4654, 2006. 766 [16] Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast 767 Congestion Control Scheme.", SIGCOMM CCR vol. 30.4, pp. 768 17-28, 2000, 2000. 770 [17] McCanne, S., Jacobson, V., and M. Vetterli, "Receiver- 771 driven Layered Multicast.", SIGCOMM CCR pp. 117-130, 1996. 773 [18] Chen, J., Arumaithurai, M., Fu, X., and KK. Ramakrishnan, 774 "SAID: A Control Protocol for Scalable and Adaptive 775 Information Dissemination in ICN.", arXiv vol. 1510.08530, 776 2015. 778 [19] Floyd, S., Jacobson, V., Liu, C., McCanne, S., and L. 779 Zhang, "A Reliable Multicast Framework for Light-Weight 780 Sessions and Application Level Framing.", IEEE TON vol. 781 5(6), pp. 784-803, 1997. 783 [20] Floyd, N., Grossglauser, M., and KK. Ramakrishnan, 784 "Distrust and Privacy: Axioms for Multicast Congestion 785 Control.", Distrust and Privacy: Axioms for Multicast 786 Congestion Control NOSSDAV, 1999. 788 Authors' Addresses 790 Ravishankar Ravindran 791 Huawei Technologies 792 2330 Central Expressway 793 Santa Clara, CA 95050 794 USA 796 Email: ravi.ravindran@huawei.com 798 Asit Chakraborti 799 Huawei Technologies 800 2330 Central Expressway 801 Santa Clara, CA 95050 802 USA 804 Email: asit.chakraborti@huawei.com 805 Syed Obaid Amin 806 Huawei Technologies 807 2330 Central Expressway 808 Santa Clara, CA 95050 809 USA 811 Email: obaid.amin@huawei.com 813 Jiachen Chen 814 Winlab, Rutgers University 815 671, U.S 1 816 North Brunswick, NJ 08902 817 USA 819 Email: jiachen@winlab.rutgers.edu 821 Marc Mosko 822 PARC 823 Palo Alto, California 94304 824 USA 826 Phone: +01 650-812-4405 827 Email: marc.mosko@parc.com 829 Ignacio Solis 830 PARC 831 Palo Alto, California 94304 832 USA 834 Phone: +01 650-812-4405 835 Email: ignacio.solis@parc.com