idnits 2.17.1 draft-bhattacharyya-core-a-realist-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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 325: '... option and MUST be accompanied w...' RFC 2119 keyword, line 382: '... MUST wait to send any further segme...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 449 has weird spacing: '...rs that can b...' -- The document date (October 7, 2018) is 2028 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2616' is defined on line 627, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7967 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CoRE A. Bhattacharyya 2 Internet Draft S. Agrawal 3 Intended status: Standards Track H. Rath 4 Expires: April 2019 A. Pal 5 B. Purushothaman 6 TATA CONSULTANCY SERVICES LTD. 7 October 7, 2018 9 Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST) 10 draft-bhattacharyya-core-a-realist-00 12 Abstract 14 This draft presents extensions to Constrained Application Protocol 15 (CoAP) to enable RESTful Real-time Live Streaming for improving the 16 Quality of Experience (QoE) for delay-sensitive Internet of Things 17 (IoT) applications. The overall architecture is termed ''Adaptive 18 RESTful Real-time Live Streaming for Things (A-REaLiST)''. It is 19 particularly designed for applications which rely on real-time 20 augmented vision through live First Person View (FPV) feed from 21 constrained remote agents like Unmanned Aerial Vehicle (UAV), etc. 22 These extensions provide the necessary hooks to help solution 23 designers ensure low-latency transfer of streams and, for contents 24 like video, a quick recovery from freeze and corruption without 25 incurring undue lag. A-REaLiST is an attempt to provide an 26 integrated approach to maintain the balance amongst QoE, resource- 27 efficiency and loss resilience. It provides the necessary hooks to 28 optimize system performance by leveraging contextual intelligence 29 inferred from instantaneous information segments in flight. These 30 extensions equip CoAP with a standard for efficient RESTful 31 streaming for Internet of Things (IoT) contrary to HTTP-streaming in 32 conventional Internet. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six 45 months and may be updated, replaced, or obsoleted by other documents 46 at any time. It is inappropriate to use Internet-Drafts as 47 reference material or to cite them other than as "work in progress." 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF), its areas, and its working groups. Note that 51 other groups may also distribute working documents as Internet- 52 Drafts. 54 Internet-Drafts are draft documents valid for a maximum of six 55 months and may be updated, replaced, or obsoleted by other documents 56 at any time. It is inappropriate to use Internet-Drafts as 57 reference material or to cite them other than as "work in progress." 59 The list of current Internet-Drafts can be accessed at 60 http://www.ietf.org/ietf/1id-abstracts.txt 62 The list of Internet-Draft Shadow Directories can be accessed at 63 http://www.ietf.org/shadow.html 65 This Internet-Draft will expire on April 7, 2019. 67 Copyright Notice 69 Copyright (c) 2018 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (http://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with 77 respect to this document. Code Components extracted from this 78 document must include Simplified BSD License text as described in 79 Section 4.e of the Trust Legal Provisions and are provided without 80 warranty as described in the Simplified BSD License. 82 Table of Contents 84 1. Introduction...................................................3 85 2. Revisiting CoAP................................................5 86 2.1. Some Interesting Aspects of CoAP..........................5 87 2.2. The Prevalent Approaches for Streaming over Internet......5 88 2.3. CoAP as the Best of Two Worlds............................6 89 3. The Approach behind A-REaLiST..................................6 90 3.1. Optional Context Aware Semantic Switch....................6 91 4. The Options Introduced.........................................7 92 5. The Handshake and Exchange Semantics...........................8 93 5.1. Initial Negotiation.......................................9 94 5.2. Renegotiation............................................11 95 6. Some Design Guidelines........................................13 96 6.1. Implicit Congestion Avoidance............................13 97 6.2. Considerations for Consumer-side Rendering...............13 98 7. IANA Considerations...........................................14 99 8. Security Considerations.......................................14 100 9. References....................................................14 101 9.1. Normative References.....................................14 102 9.2. Informative References...................................15 104 1. Introduction 106 IoT emerged to facilitate exchange of frequent-but-small sensory 107 information amongst numerous constrained sensors [IOT- 108 ISOC][RFC7452]. However, recent trends in industry and research 109 community realize the importance of live visual data as important 110 sensory information. There are many discourses available to support 111 this observation [Murphy]. Live First Person View (FPV) from 112 Unmanned Aerial Vehicles (UAV) and dumb robot terminals are being 113 used for futuristic remote control and actuation applications for 114 Augmented Reality (AR), Visual Simultaneous Localization and Mapping 115 (VSLAM), UAV based surveillance, etc. Efficacy of these applications 116 depends on resource-efficient, low-latency, yet high QoE transfer of 117 the FPV over the Internet (or IP networks in general). Contrary to 118 the traditional video streaming applications, the UAV-like end- 119 points (henceforth referred as 'video producer') that capture and 120 transmit the FPV are resource constrained devices. Moreover, the 121 producer may work in a lossy environment marred with fluctuating 122 radio connectivity and disruptions due network congestion. 124 The QoE considerations of the video rendering unit (henceforth 125 referred as 'video consumer') for these applications are quite 126 different from traditional applications. For example, in case of 127 highly delay sensitive AR applications, a human brain may not 128 tolerate a noticeable video freeze or delayed reception, which might 129 have been overlooked for usual content delivery service like a 130 YouTube video. Such delay may result in wrong actuation. For 131 example, delayed FPV from a UAV may lead to wrong control commands 132 leading to catastrophic consequences. In addition, the communication 133 should be as light-weight as possible to optimize the usage of on- 134 board computing and energy resources of the UAV. So, real-time video 135 transmissions for IoT applications require special treatment 136 [Pereira]. However, as revealed through a detail analysis of the 137 state-of-the-art in the next section, the existing solutions do not 138 address such special requirements. This draft attempts to bridge 139 this important gap by extending CoAP [RFC7252]. 141 To realize its purpose, the A-REaLiST architecture relies on 142 [RFC7967] and adds few new header options which, taken together, can 143 be conceived to form a conceptual 'Stream' extension on CoAP (Fig. 144 1). 146 +----------------------+ 147 | Application | 148 +----------------------+ ---- 149 | Stream | \ 150 |----------------------| \ |CoAP 151 | Requests/Responses | | |extended 152 |----------------------| | CoAP |for 153 | Messages | | / A-REaLiST 154 +----------------------+ / ---- 155 +----------------------+ 156 | UDP | 157 +----------------------+ 159 Figure 1: Abstract extended layering of CoAP for A-REaLiST with the 160 conceptual layer for streaming. 162 Though primarily designed for video streaming, these extensions can 163 also be used to allow streaming of time-series information on CoAP. 165 Note: Block-wise transfer [RFC7959] is a standardized extension to 166 CoAP for transferring large application data. The cited use case 167 for this is to perform firmware upgrade for a large number of 168 constrained devices. Block-wise transfer is primarily concerned 169 with reliable delivery of information. It works in synchronized 170 manner. If a message remains unacknowledged despite 171 retransmissions then the whole exchange is cancelled. So, it is 172 not suitable for real-time delivery [GIoTS] which is requirement 173 for many time-series information streams including video. 175 2. Revisiting CoAP 177 2.1. Some Interesting Aspects of CoAP 179 ( i) CoAP allows both confirmable (CON) and non-confirmable (NON) 180 messaging. 182 ( ii) CON mode enables CoAP with an option for reliable RESTful 183 delivery like HTTP [RFC2616]on TCP. On the other hand, 184 intelligent use of No-Response option [RFC7967] along with NON 185 mode can create an RTP like best-effort messaging on UDP. 187 (iii) Context based switching between the reliable and best-effort 188 semantics can be executed from the end-application level. This 189 way an optimum balance between reliability delay-performance can 190 be maintained to improve the overall Quality of Experience (QoE). 192 ( iv) The base CoAP specification is inherently designed for 193 resource constrained devices. Hence, a streaming protocol using 194 the stateless RESTful semantics on CoAP makes the solution 195 inherently lightweight. So, unlike conventional approach the 196 designers can use a single stack that is equally efficient for 197 sending the small data out of sensors, as well as, infinite 198 visual stream. 200 2.2. The Prevalent Approaches for Streaming over Internet 202 The two prevalent approaches for streaming over the Internet are as 203 below. 205 First approach is to send the information segment over HTTP which 206 uses the reliability feature of the underlying Transmission Control 207 Protocol (TCP) transport. In this case TCP state-machine puts more 208 emphasis on reliable delivery of segments rather than maintaining 209 the real-time deadlines. However, this is right now the prevalent 210 approach as it treats video and other streams as general Internet 211 traffic. So, streaming can seamlessly co-exist with the existing 212 Internet architecture. Also, since TCP takes care of ordered 213 delivery, the end-application does not need to worry about these 214 matters. 216 The other approach is to use a specialized protocol like Real-time 217 Transport Protocol (RTP) [RFC3550]. It treats video and other real- 218 time streams as a special type of traffic. To ensure real-time 219 delivery, the data is delivered in best-effort manner on top of UDP. 220 So, reliable delivery is undermined. 222 2.3. CoAP as the Best of Two Worlds 224 It can be conjectured, tallying the above with previous section, 225 that CoAP inherently imbibes the functional features from HTTP-on- 226 TCP (reliable delivery) and RTP-on-UDP (best-effort delivery). 227 Further CoAP allows the switching between these two seamlessly just 228 by maneuvering the header options. 230 3. The Approach behind A-REaLiST 232 The design stems from the principles of ''progressive download'' on 233 top of the RESTful request/response semantics of CoAP. The 234 ''producer'' chunks the continuous information stream into segments as 235 per the agreed maximum payload size suggested in [RFC7252]. Each 236 chunk is transmitted as a CoAP request to a given resource at the 237 ''consumer''. This draft provides the necessary header extensions that 238 enable the ''consumer'' to maintain the sequence of the information 239 segments in time and space. 241 3.1. Optional Context Aware Semantic Switch 243 Before forming the CoAP message for each segment, the streaming 244 application may use a real-time analytics module (henceforth 245 referred as 'analytics module') which may provide inference to the 246 ''Stream'' layer to decide the exchange semantics for the current 247 segment. The message is sent reliably (CON message) or as best- 248 effort (NON message with No-Response option) based on the segment's 249 information criticality. Criticality is measured in terms of 250 importance of the segment-content in reconstruction of the frames at 251 the consumer. However, determination of criticality can be done on 252 many aspects involving several application features like the source 253 encoding type, the rendering logic at the consumer, etc. This way 254 the over-all balance between QoE and resource-consumption may be 255 maintained. Fig. 2 explains the idea with conceptual blocks. The 256 overall concept and its efficacy has been explained with 257 experimental results in [Wi-UAV-Globecom] 259 +----------------------+ 260 | Application | Information segment --------- 261 +----------------------+ ====================> |Real-time| 262 | Stream | <==================== |Analytics| 263 |----------------------| Reliable/ --------- 264 | Requests/Responses | Best-effort? 265 |----------------------| 266 | Messages | 267 +----------------------+ 269 Figure 2: Illustrating the concept for context aware switching 271 Some examples are: 273 Example-1: Temporally compressed videos like MPEG consist of Group 274 of Pictures (GoP) which comprises I-frames (Intra-frames) or key- 275 frames, P-frames (Predicted frames) and B-frames (Bidirectional 276 frames). Out of these 3 types of frames I-frames are most 277 critical in terms of synchronizing with the GoP at the receiver 278 end for successful rendering. So, an analytics module at the 279 ''video producer'' end may infer each information segments of I- 280 frames as critical and send those segments reliably. The segments 281 corresponding to P and B frames may be transferred as best-effort 282 requests. 284 Example-2: Let us consider a Motion JPEG (MJPEG) stream. In this 285 case all the frames are independent JPEG frames and there is no 286 temporal compression. The analytics module may treat the segments 287 containing MJPEG meta-data for each frame as critical segments 288 and transfer them through reliable messaging. Rest of the 289 segments may be transferred as best-effort requests. An 290 intelligent rendering engine at the ''consumer'' application may 291 compensate for / conceal any possible loss of non-meta-data (non- 292 critical) segments using the reliably received meta-data and rest 293 of the non-meta-data segments received through best-effort. This 294 way high QoE can be ensured despite reduced resource usage. 296 4. The Options Introduced 298 To achieve the purpose of the Stream layer, three new protocol 299 header options have been proposed as below: 300 1) Stream_info: Consumes one unsigned byte. It maintains the stream 301 identity and indicates the present phase of exchange. It is both 302 a request and response option. It has two fields. The 3-LSBs 303 indicate the state of exchange (Stream_state) and 5-MSBs indicate 304 an identifier (Stream_id) for the stream. The identifier remains 305 unchanged for the entire stream. So, 307 Stream_id = Stream_info >> 3; 308 Stream_ state = Stream_info & 0x7. 310 Interpretation of Stream_state bits are : 311 000=> stream initiation (always with request); 313 001=> initiation accepted (always with response); 314 010=> initiation rejected (always with response); 316 011=> stream re-negotiation (with request or response); 318 100=> stream ongoing. 320 2) Time-stamp: It consumes 32-bit unsigned integer. It is a request 321 option. It relates a particular application information segment 322 to the corresponding frame in the play sequence. 324 3) Position: It consumes 16-bit unsigned integer. It is a request 325 option and MUST be accompanied with the Time-stamp option. It is 326 a combination of two fields. The 15-MSBs indicate the ''offset'' at 327 which the present segment is placed in the frame corresponding to 328 the given timestamp. The LSB indicates if the current segment is 329 the last segment of the frame corresponding to the given 330 timestamp. Hence, 331 Last_segment = Position &0x01 ? True : False; 332 Offset = (Position >> 1). 334 +-----+---+---+---+---+--------------+--------+--------+---------+ 335 | No. | C | U | N | R | Name | Format | Length | Default | 336 +-----+---+---+---+---+--------------+--------+--------+---------+ 337 | TBD | X | | - | | Stream-info | uint | 1 | (none) | 338 +-----+---+---+---+---+--------------+--------+--------+---------+ 339 | TBD | X | | - | | Time-stamp | uint | 4 | (none) | 340 +-----+---+---+---+---+--------------+--------+--------+---------+ 341 | TBD | X | | - | | Position | uint | 2 | (none) | 342 +-----+---+---+---+---+--------------+--------+--------+---------+ 344 Table 1: Option Properties 346 5. The Handshake and Exchange Semantics 348 As per the design considerations in view of the scenarios conceived 349 at present, video transfer is initiated by the ''producer'' which acts 350 as the client. 352 Note: The design considerations are driven by the experiences drawn 353 from the applications where live video feeds are transmitted from 354 battery operated constrained ''video producers'' like UAVs and dumb 355 robotic terminals, etc. For example, while a fixed infrastructure 356 system is using streamed FPV feed from UAVs, there may be situations 357 where each time a UAV is low on resources (energy and computation, a 358 new UAV with better state of resources (fresh battery, etc.) is 359 commissioned. The overall operation becomes simple if the newly 360 commissioned UAV readily starts its job by streaming to the same 361 resource at the fixed infrastructure. It can be easily configured to 362 determine whether the consumer is up and watching by observing the 363 responses to the CON requests. In case the exchange is initiated by 364 the consumer then whenever a new UAV is commissioned, the consumer 365 has to re-initiate the request again. 367 Each segment is transmitted to the ''video consumer'' as a POST 368 request. The Time-stamp and Position options help sequential 369 ordering of the segments at the consumer. 371 5.1. Initial Negotiation 373 Initial negotiations for frame rate, video type, encoding details, 374 etc., are performed by exchanging configuration scripts (cbor or 375 json) over POST request. Exact format of the script is application 376 dependent and is not part of this draft. 378 Fig. 3 illustrates the exemplary exchanges related to handshakes for 379 connection initiation. 381 Note: All reliable transfers are in blocking mode. So, the producer 382 MUST wait to send any further segment (critical/ on-critical) till 383 the response is received for the critical segment. Please refer to 384 Section 6 for suggested behavior in case a reliable transfer fails. 386 Client (Producer) Server (Consumer) 387 | | 388 | POST: CON; | 389 | URI=/video; | 390 | Stream-info = <5-bit ID>000; | 391 | Payload= CBOR or JSON |\ 392 +------------------------------------------------->| | 393 | | |Stream 394 | ACK; | |negotiation 395 | Response = 2.04 CHANGED | | 396 | Steam-info = <5-bit ID>001 | | 397 |<-------------------------------------------------|/ 398 : : 399 : : 400 |(First segment of an MJPEG frame. Contains | 401 | meta-data. Critical segment needs reliable | 402 | delivery.) | 403 | | 404 | POST: CON; | 405 | URI=/video; | 406 | Stream-info = <5-bit ID>100; | 407 | Time-stamp = ; | 408 | Position = 0; | 409 | Payload= |\ 410 +------------------------------------------------->| | 411 | | | 412 | ACK; | | 413 | Response = 2.04 CHANGED | | 414 | Steam-info = <5-bit ID>100 | | 415 |<-------------------------------------------------| | 416 |(Second segment of an MJPEG frame. Contains | | 417 | non-meta-data. Non-critical segment- best effort | | 418 | transfer.) | | 419 | | | Stream 420 | POST: NON; | | ongoing 421 | URI=/video; No-response = 127 | | 422 | Stream-info = <5-bit ID>100; | | 423 | Time-stamp = ; | | 424 | Position = 1024; | | 425 | Payload= | | 426 +------------------------------------------------->| | 427 | | | 428 : : | 429 Figure 3: Example showing successful negotiation of streaming 430 parameters followed by transmission of video information and 431 control. It is assumed that the segment size negotiated as 1024 at 432 the initiation. So, the position of the 2nd block is 1024. Note the 433 use of No-response option with NON request for the non-critical 434 segment. 436 5.2. Renegotiation 438 The renegotiation phase may occur when the ''consumer'' does not agree 439 to parameters proposed by the producer and proposes a modified set. 440 This may happen when the consumer application may need a less frame- 441 rate than what is proposed by the producer. So, the ''consumer'' may 442 request a lower frame-rate and thereby avoid unnecessary traffic in 443 the network. The reduction may also be driven by the processing load 444 on the producer which is anyway a constrained device. So, if a 445 consumer requests more frame-rate than what is initially proposed by 446 the producer, then the producer may insist on the lower frame-rate. 447 Renegotiation may also occur if, during a stream, the producer 448 senses a change in the end-to-end channel condition and proposes a 449 new set of best possible parameters that can be served to the 450 consumer. 452 Note that, that the consumer is never allowed to exceed the limits 453 advertised by the producer. 455 Fig. 4 illustrates exemplary exchanges for re-negotiation. 457 Client (Producer) Server (Consumer) 458 | | 459 | POST: CON; | 460 | URI=/video; | 461 | Stream-info = <5-bit ID>000; | 462 | Payload= CBOR or JSON |\ Initial 463 +------------------------------------------------->| |negotiation 464 | | |followed by 465 | ACK; | |renegotiation 466 | Response = 2.04 CHANGED | |request with 467 | Steam-info = <5-bit ID>010 | |revised 468 | Payload= CBOR or JSON | |params. 469 |<-------------------------------------------------|/ 470 | | 471 | POST: CON; | 472 | URI=/video; | 473 | Stream-info = <5-bit ID>010; | 474 | Payload= CBOR or JSON |\ Successful 475 +------------------------------------------------->| |renegotiation 476 | | |as the 477 | ACK; | |consumer 478 | Response = 2.04 CHANGED | |agrees to the 479 | Steam-info = <5-bit ID>001 | |revised 480 |<-------------------------------------------------|/ proposal. 481 : : 482 : (Streaming starts) : 484 Figure 4: Example showing successful renegotiation of streaming 485 parameters. Note the maneuvering of the Stream-info bit patterns. 487 Fig. 5 illustrates exemplary exchanges when a stream negotiation is 488 unsuccessful. The accompanied script may provide hints to the reason 489 for unsuccessful negotiations. A simple case of unsuccessful attempt 490 may be observed if the resource on the ''consumer'' side is not ready. 491 The exact formatting of the script is not in the scope of this 492 draft. 494 Client (Producer) Server (Consumer) 495 | | 496 | POST: CON; | 497 | URI=/video; | 498 | Stream-info = <5-bit ID>000; | 499 | Payload= CBOR or JSON |\ Unsuccessful 500 +------------------------------------------------->| |negotiation. 501 | | |The request 502 | ACK; | |is successful. 503 | Response = 2.04 CHANGED | |But consumer 504 | Steam-info = <5-bit ID>011 | |may reject 505 | Payload= CBOR or JSON | |for some 506 |<-------------------------------------------------|/ reason 507 | | mentioned in 508 Script. 510 Figure 5: Example showing unsuccessful renegotiation despite 511 successful response code against the initiation request. 513 6. Some Design Guidelines 515 6.1. Implicit Congestion Avoidance 517 The throughput and resource optimization for A-REaLiST depends 518 largely on the best-effort delivery on UDP. Despite that the 519 application designer can make A-REaLiST implicitly congestion aware 520 and proactively avoid congestion. CoAP has a basic congestion 521 avoidance mechanism which uses exponential back off to increase the 522 timeout for retransmissions. However, that works only for CON 523 messages. 525 The implicit congestion avoidance works like this: In case the 526 producer fails to successfully transfer a critical segment of a 527 frame within the MAX_TRANSMIT_SPAN as well as within MAX_RETRANSMIT 528 [RFC7252] attempts, the producer drops transmission of rest of the 529 segments in that frame and waits for the next frame to be ready. The 530 rationale is, since the critical segment is not delivered, the 531 consumer will fail to reconstruct this frame anyway. So, there is no 532 point in clogging the network with rest of the segments. 534 6.2. Considerations for Consumer-side Rendering 536 While the critical segments are delivered reliably in a sequential 537 manner, non-critical are delivered with best-effort in an open-loop 538 exchange. Also, the whole frame can be dropped to avoid congestion. 539 Hence, the application at the ''consumer'' end-point (server) needs to 540 deal with issues like out-of-order delivery, frame/segment loss, 541 asynchronous segment arrival. 543 The issues mentioned above have been discussed in literatures 544 [Perkins]. So the basic approach should be: Buffer till a critical 545 time to iron out the jittery, out-of-order arrival of the segments, 546 play out from the appropriate buffer at a constant rate determined 547 by the frame-rate of the video. There may be intelligent algorithms 548 to play-out with high QoE despite non-arrival of non-critical 549 segments within the play-out deadline. This draft provides the hooks 550 to create such designs. Reference architecture of the play-out 551 mechanism is provided in [Wi-UAV-Globecom]. The play-out 552 architecture leverages on the design assumption about the 'less- 553 constrained' nature of the consumer in terms of memory and 554 processor. 556 7. IANA Considerations 558 The IANA is requested to assign numbers to the three options 559 introduced in this draft for inclusion in the ''CoAP Option Numbers" 560 registry as shown below. 562 +--------+--------------+-------------+ 563 | Number | Name | Reference | 564 +--------+--------------+-------------+ 565 | TBD | Stream-info | Section 4 | 566 +--------+--------------+-------------+ 567 | TBD | Time-stamp | Section 4 | 568 +--------+--------------+-------------+ 569 | TBD | Position | Section 4 | 570 +--------+--------------+-------------+ 572 8. Security Considerations 574 This draft presents no security considerations beyond those in 575 Section 11 of the base CoAP specification [RFC7252]. 577 9. References 579 9.1. Normative References 581 [RFC7252] 583 Shelby, Z., Hartke, K. and Bormann, C.,"Constrained Application 584 Protocol (CoAP)", RFC 7252, June, 2014. 586 [RFC7967] 587 Bhattacharyya, A., Bandyopadhyay, S., Pal, A., Bose, T., 588 ''Constrained Application Protocol (CoAP) Option for No Server 589 Response'', RFC 7967, August, 2016. 591 9.2. Informative References 593 [IOT-ISOC] 595 Rose, K., Eldridge, S., Chapin, L., ''The Internet of Things: an 596 overview'', Internet Society, pp.1-50, October, 2015. 598 [RFC7452] 600 Tschofenig, H., Arkko, J., McPherson, D., "Architectural 601 Considerations in Smart Object Networking", RFC 7452, March, 2015. 603 [Murphy] 605 Murphy, C., ''Internet of Things: Are you underestimating video?'', 606 Available online: 607 http://www.informationweek.com/bigdata/bigdataanalytics/internetofth 608 ingsareyouunderestimatingvideo/a/d-id/1269508, June, 2014. 610 [Pereira] 612 Pereira, R., Pereira, E. G., ''Video Streaming Considerations for 613 Internet of Things'', International Conference on Future Internet of 614 Things and Cloud, pp. 48-52, August, 2014. 616 [RFC7959] 618 Bormann, C., Shelby, Z., ''Block-Wise Transfers in the Constrained 619 Application Protocol (CoAP)'', RFC 7959, August, 2016. 621 [GIoTS] 623 Dey, S., Bhattacharyya, A., Mukherjee, A., "Semantic data exchange 624 between collaborative robots in fog environment: Can CoAP be a 625 choice?", Global IoTS, pp. 1-6, June, 2017. 627 [RFC2616] 629 Fielding, R., Irvine, U.C., Gettys, J., Mogul, J., Frystyk, H., 630 Masinter, L., Leach, P., Berners-Lee, T., ''Hypertext Transfer 631 Protocol -- HTTP/1.1'', RFC 2616, June, 1999. 633 [RFC3550] 635 Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., ''RTP: A 636 Transport Protocol for Real-Time Applications'', RFC 3550, July, 637 2003. 639 [Wi-UAV-Globecom] 641 Bhattacharyya, A., Agrawal, S., Rath, H., Pal, A., ''Improving Live- 642 streaming Experience for Delay-sensitive IoT Applications : A 643 RESTful Approach'', accepted in Globecom (Wi-UAV workshop), Dec., 644 2018. 646 [Perkins] 648 Perkins, C., ''RTP: Audio and Video for the Internet'', Addison- 649 Wesley, 2003. 651 Authors' Addresses 653 Abhijan Bhattacharyya 654 Tata Consultancy Services Ltd. 655 Kolkata, India 657 Email: abhijan.bhattacharyya@tcs.com 659 Suvrat Agrawal 660 Tata Consultancy Services Ltd. 661 Bangalore, India 663 Email: suvrat.a@tcs.com 665 Hemant Rath 666 Tata Consultancy Services Ltd. 667 Bhubaneswar, India 669 Email: hemant.rath@tcs.com 671 Arpan Pal 672 Tata Consultancy Services Ltd. 673 Kolkata, India 675 Email: arpan.pal@tcs.com 677 Balamurali Purushothaman 678 Tata Consultancy Services Ltd. 679 Bangalore, India 681 Email: arpan.pal@tcs.com