idnits 2.17.1 draft-bhattacharyya-core-a-realist-02.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 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 333: '... option and MUST be accompanied w...' RFC 2119 keyword, line 391: '... MUST wait to send any further se...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 459 has weird spacing: '...rs that can b...' -- The document date (February 6, 2019) is 1906 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 653, 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: 2 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: August 2019 A. Pal 5 B. Purushothaman 6 TATA CONSULTANCY SERVICES LTD. 7 February 6, 2019 9 Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST) 10 draft-bhattacharyya-core-a-realist-02 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 August 6, 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 6.3. Determining the segment size.............................14 99 7. IANA Considerations...........................................14 100 8. Security Considerations.......................................15 101 9. References....................................................15 102 9.1. Normative References.....................................15 103 9.2. Informative References...................................15 105 1. Introduction 107 IoT emerged to facilitate exchange of frequent-but-small sensory 108 information amongst numerous constrained sensors [IOT- 109 ISOC][RFC7452]. However, recent trends in industry and research 110 community realize the importance of live visual data as important 111 sensory information. There are many discourses available to support 112 this observation [Murphy]. Live First Person View (FPV) from 113 Unmanned Aerial Vehicles (UAV) and dumb robot terminals are being 114 used for futuristic remote control and actuation applications for 115 Augmented Reality (AR), Visual Simultaneous Localization and Mapping 116 (VSLAM), UAV based surveillance, etc. Efficacy of these applications 117 depends on resource-efficient, low-latency, yet high QoE transfer of 118 the FPV over the Internet (or IP networks in general). Contrary to 119 the traditional video streaming applications, the UAV-like end- 120 points (henceforth referred as 'video producer') that capture and 121 transmit the FPV are resource constrained devices. Moreover, the 122 producer may work in a lossy environment marred with fluctuating 123 radio connectivity and disruptions due network congestion. 125 The QoE considerations of the video rendering unit (henceforth 126 referred as 'video consumer') for these applications are quite 127 different from traditional applications. For example, in case of 128 highly delay sensitive AR applications, a human brain may not 129 tolerate a noticeable video freeze or delayed reception, which might 130 have been overlooked for usual content delivery service like a 131 YouTube video. Such delay may result in wrong actuation. For 132 example, delayed FPV from a UAV may lead to wrong control commands 133 leading to catastrophic consequences. In addition, the communication 134 should be as light-weight as possible to optimize the usage of on- 135 board computing and energy resources of the UAV. So, real-time video 136 transmissions for IoT applications require special treatment 138 [Pereira]. However, as revealed through a detail analysis of the 139 state-of-the-art in the next section, the existing solutions do not 140 address such special requirements. This draft attempts to bridge 141 this important gap by extending CoAP [RFC7252]. 143 To realize its purpose, the A-REaLiST architecture relies on 144 [RFC7967] and adds few new header options which, taken together, can 145 be conceived to form a conceptual 'Stream' extension on CoAP (Fig. 146 1). 148 +----------------------+ 149 | Application | 150 +----------------------+ ---- 151 | Stream | \ 152 |----------------------| \ |CoAP 153 | Requests/Responses | | |extended 154 |----------------------| | CoAP |for 155 | Messages | | / A-REaLiST 156 +----------------------+ / ---- 157 +----------------------+ 158 | UDP | 159 +----------------------+ 161 Figure 1: Abstract extended layering of CoAP for A-REaLiST with the 162 conceptual layer for streaming. 164 Though primarily designed for video streaming, these extensions can 165 also be used to allow streaming of time-series information on CoAP. 167 Note: Block-wise transfer [RFC7959] is a standardized extension to 168 CoAP for transferring large application data. The cited use case 169 for this is to perform firmware upgrade for a large number of 170 constrained devices. Block-wise transfer is primarily concerned 171 with reliable delivery of information. It works in synchronized 172 manner. If a message remains unacknowledged despite 173 retransmissions then the whole exchange is cancelled. So, it is 174 not suitable for real-time delivery [GIoTS] which is requirement 175 for many time-series information streams including video. 177 2. Revisiting CoAP 179 2.1. Some Interesting Aspects of CoAP 181 ( i) CoAP allows both confirmable (CON) and non-confirmable (NON) 182 messaging. 184 ( ii) CON mode enables CoAP with an option for reliable RESTful 185 delivery like HTTP [RFC2616]on TCP. On the other hand, 186 intelligent use of No-Response option [RFC7967] along with NON 187 mode can create an RTP like best-effort messaging on UDP. 189 (iii) Context based switching between the reliable and best-effort 190 semantics can be executed from the end-application level. This 191 way an optimum balance between reliability delay-performance can 192 be maintained to improve the overall Quality of Experience (QoE). 194 ( iv) The base CoAP specification is inherently designed for 195 resource constrained devices. Hence, a streaming protocol using 196 the stateless RESTful semantics on CoAP makes the solution 197 inherently lightweight. So, unlike conventional approach the 198 designers can use a single stack that is equally efficient for 199 sending the small data out of sensors, as well as, infinite 200 visual stream. 202 2.2. The Prevalent Approaches for Streaming over Internet 204 The two prevalent approaches for streaming over the Internet are as 205 below. 207 First approach is to send the information segment over HTTP which 208 uses the reliability feature of the underlying Transmission Control 209 Protocol (TCP) transport. In this case TCP state-machine puts more 210 emphasis on reliable delivery of segments rather than maintaining 211 the real-time deadlines. However, this is right now the prevalent 212 approach as it treats video and other streams as general Internet 213 traffic. So, streaming can seamlessly co-exist with the existing 214 Internet architecture. Also, since TCP takes care of ordered 215 delivery, the end-application does not need to worry about these 216 matters. 218 The other approach is to use a specialized protocol like Real-time 219 Transport Protocol (RTP) [RFC3550]. It treats video and other real- 220 time streams as a special type of traffic. To ensure real-time 221 delivery, the data is delivered in best-effort manner on top of UDP. 222 So, reliable delivery is undermined. 224 2.3. CoAP as the Best of Two Worlds 226 It can be conjectured, tallying the above with previous section, 227 that CoAP inherently imbibes the functional features from HTTP-on- 228 TCP (reliable delivery) and RTP-on-UDP (best-effort delivery). 229 Further CoAP allows the switching between these two seamlessly just 230 by maneuvering the header options. 232 3. The Approach behind A-REaLiST 234 The design stems from the principles of "progressive download" on 235 top of the RESTful request/response semantics of CoAP. The 236 "producer" chunks the continuous information stream into segments as 237 per the agreed maximum payload size suggested in [RFC7252]. Each 238 chunk is transmitted as a CoAP request to a given resource at the 239 "consumer". This draft provides the necessary header extensions that 240 enable the "consumer" to maintain the sequence of the information 241 segments in time and space. 243 3.1. Optional Context Aware Semantic Switch 245 Before forming the CoAP message for each segment, the streaming 246 application may use a real-time analytics module (henceforth 247 referred as 'analytics module') which may provide inference to the 248 "Stream" layer to decide the exchange semantics for the current 249 segment. The message is sent reliably (CON message) or as best- 250 effort (NON message with No-Response option) based on the segment's 251 information criticality. Criticality is measured in terms of 252 importance of the segment-content in reconstruction of the frames at 253 the consumer. However, determination of criticality can be done on 254 many aspects involving several application features like the source 255 encoding type, the rendering logic at the consumer, etc. This way 256 the over-all balance between QoE and resource-consumption may be 257 maintained. Fig. 2 explains the idea with conceptual blocks. The 258 overall concept and its efficacy has been explained with 259 experimental results in [Wi-UAV-Globecom] 261 +----------------------+ 262 | Application | Information segment --------- 263 +----------------------+ ====================> |Real-time| 264 | Stream | <==================== |Analytics| 265 |----------------------| Reliable/ --------- 266 | Requests/Responses | Best-effort? 267 |----------------------| 268 | Messages | 269 +----------------------+ 271 Figure 2: Illustrating the concept for context aware switching 273 Some examples are: 275 Example-1: Temporally compressed videos like MPEG consist of Group 276 of Pictures (GoP) which comprises I-frames (Intra-frames) or key- 277 frames, P-frames (Predicted frames) and B-frames (Bidirectional 278 frames). Out of these 3 types of frames I-frames are most 279 critical in terms of synchronizing with the GoP at the receiver 280 end for successful rendering. So, an analytics module at the 281 "video producer" end may infer each information segments of I- 282 frames as critical and send those segments reliably. The segments 283 corresponding to P and B frames may be transferred as best-effort 284 requests. 286 Example-2: Let us consider a Motion JPEG (MJPEG) stream. In this 287 case all the frames are independent JPEG frames and there is no 288 temporal compression. The analytics module may treat the segments 289 containing MJPEG meta-data for each frame as critical segments 290 and transfer them through reliable messaging. Rest of the 291 segments may be transferred as best-effort requests. An 292 intelligent rendering engine at the "consumer" application may 293 compensate for / conceal any possible loss of non-meta-data (non- 294 critical) segments using the reliably received meta-data and rest 295 of the non-meta-data segments received through best-effort. This 296 way high QoE can be ensured despite reduced resource usage. 298 4. The Options Introduced 300 To achieve the purpose of the Stream layer, three new protocol 301 header options have been proposed as below: 302 1) Stream_info: Consumes one unsigned byte. It maintains the stream 303 identity and indicates the present phase of exchange. It is both 304 a request and response option. It has two fields. The 3-LSBs 305 indicate the state of exchange (Stream_state) and 5-MSBs indicate 306 an identifier (Stream_id) for the stream. The identifier remains 307 unchanged for the entire stream. So, 309 Stream_id = Stream_info >> 3; 310 Stream_ state = Stream_info & 0x7. 312 Interpretation of Stream_state bits are : 313 000=> stream initiation (always with request); 315 001=> initiation accepted (always with response); 316 010=> initiation rejected (always with response); 318 011=> stream re-negotiation (with request or response); 320 100=> stream ongoing. 322 Note: While Stream_id field enables to uniquely identify an 323 information stream, it may also be used by an application to 324 relate the context of different sub-streams (may be with 325 varying QoS) and produce a combined rendering at the 326 consumer-end. 328 2) Time-stamp: It consumes 32-bit unsigned integer. It is a request 329 option. It relates a particular application information segment 330 to the corresponding frame in the play sequence. 332 3) Position: It consumes 16-bit unsigned integer. It is a request 333 option and MUST be accompanied with the Time-stamp option. It is 334 a combination of two fields. The 15-MSBs indicate the "offset" at 335 which the present segment is placed in the frame corresponding to 336 the given timestamp. The LSB indicates if the current segment is 337 the last segment of the frame corresponding to the given 338 timestamp. Hence, 339 Last_segment = Position &0x01 ? True : False; 340 Offset = (Position >> 1). 342 +-----+---+---+---+---+--------------+--------+--------+---------+ 343 | No. | C | U | N | R | Name | Format | Length | Default | 344 +-----+---+---+---+---+--------------+--------+--------+---------+ 345 | TBD | X | | - | | Stream-info | uint | 1 | (none) | 346 +-----+---+---+---+---+--------------+--------+--------+---------+ 347 | TBD | X | | - | | Time-stamp | uint | 4 | (none) | 348 +-----+---+---+---+---+--------------+--------+--------+---------+ 349 | TBD | X | | - | | Position | uint | 2 | (none) | 350 +-----+---+---+---+---+--------------+--------+--------+---------+ 352 Table 1: Option Properties 354 5. The Handshake and Exchange Semantics 356 As per the design considerations (in view of the scenarios conceived 357 at present) video transfer is initiated by the "producer" which acts 358 as the client. 360 Each segment is transmitted to the "video consumer" as a POST 361 request. The Time-stamp and Position options help sequential 362 ordering of the segments at the consumer. 364 Note: The design considerations are driven by the experiences drawn 365 from the applications where live video feeds are transmitted from 366 battery operated constrained "video producers" like UAVs and dumb 367 robotic terminals, etc. For example, while a fixed 368 infrastructure system is using streamed FPV feed from UAVs, there 369 may be situations where each time a UAV is low on resources 370 (energy and computation, a new UAV with better state of resources 371 (fresh battery, etc.) is commissioned. The overall operation 372 becomes simple if the newly commissioned UAV readily starts its 373 job by streaming to the same resource at the fixed 374 infrastructure. It can be easily configured to determine whether 375 the consumer is up and watching by observing the responses to the 376 CON requests. In case the exchange is initiated by the consumer 377 then whenever a new UAV is commissioned, the consumer has to re- 378 initiate the request again. 380 5.1. Initial Negotiation 382 Initial negotiations for frame rate, video type, encoding details, 383 etc., are performed by exchanging configuration scripts (cbor or 384 json) over POST request. Exact format of the script is application 385 dependent and is not part of this draft. 387 Fig. 3 illustrates the exemplary exchanges related to handshakes for 388 connection initiation. 390 Note: All reliable transfers are in blocking mode. So, the producer 391 MUST wait to send any further segment (critical/ on-critical) 392 till the response is received for the critical segment. Please 393 refer to Section 6 for suggested behavior in case a reliable 394 transfer fails. 396 Client (Producer) Server (Consumer) 397 | | 398 | POST: CON; | 399 | URI=/video; | 400 | Stream-info = <5-bit ID>000; | 401 | Payload= CBOR or JSON |\ 402 +------------------------------------------------->| | 403 | | |Stream 404 | ACK; | |negotiation 405 | Response = 2.04 CHANGED | | 406 | Steam-info = <5-bit ID>001 | | 407 |<-------------------------------------------------|/ 408 : : 409 : : 410 |(First segment of an MJPEG frame. Contains | 411 | meta-data. Critical segment needs reliable | 412 | delivery.) | 413 | | 414 | POST: CON; | 415 | URI=/video; | 416 | Stream-info = <5-bit ID>100; | 417 | Time-stamp = ; | 418 | Position = 0; | 419 | Payload= |\ 420 +------------------------------------------------->| | 421 | | | 422 | ACK; | | 423 | Response = 2.04 CHANGED | | 424 | Steam-info = <5-bit ID>100 | | 425 |<-------------------------------------------------| | 426 |(Second segment of an MJPEG frame. Contains | | 427 | non-meta-data. Non-critical segment- best effort | | 428 | transfer.) | | 429 | | | Stream 430 | POST: NON; | | ongoing 431 | URI=/video; No-response = 127 | | 432 | Stream-info = <5-bit ID>100; | | 433 | Time-stamp = ; | | 434 | Position = 1024; | | 435 | Payload= | | 436 +------------------------------------------------->| | 437 | | | 438 : : | 439 Figure 3: Example showing successful negotiation of streaming 440 parameters followed by transmission of video information and 441 control. It is assumed that the segment size negotiated as 1024 at 442 the initiation. So, the position of the 2nd block is 1024. Note the 443 use of No-response option with NON request for the non-critical 444 segment. 446 5.2. Renegotiation 448 The renegotiation phase may occur when the "consumer" does not agree 449 to parameters proposed by the producer and proposes a modified set. 450 This may happen when the consumer application may need a less frame- 451 rate than what is proposed by the producer. So, the "consumer" may 452 request a lower frame-rate and thereby avoid unnecessary traffic in 453 the network. The reduction may also be driven by the processing load 454 on the producer which is anyway a constrained device. So, if a 455 consumer requests more frame-rate than what is initially proposed by 456 the producer, then the producer may insist on the lower frame-rate. 457 Renegotiation may also occur if, during a stream, the producer 458 senses a change in the end-to-end channel condition and proposes a 459 new set of best possible parameters that can be served to the 460 consumer. 462 Note that, that the consumer is never allowed to exceed the limits 463 advertised by the producer. 465 Fig. 4 illustrates exemplary exchanges for re-negotiation. 467 Client (Producer) Server (Consumer) 468 | | 469 | POST: CON; | 470 | URI=/video; | 471 | Stream-info = <5-bit ID>000; | 472 | Payload= CBOR or JSON |\ Initial 473 +------------------------------------------------->| |negotiation 474 | | |followed by 475 | ACK; | |renegotiation 476 | Response = 2.04 CHANGED | |request with 477 | Steam-info = <5-bit ID>010 | |revised 478 | Payload= CBOR or JSON | |params. 479 |<-------------------------------------------------|/ 480 | | 481 | POST: CON; | 482 | URI=/video; | 483 | Stream-info = <5-bit ID>010; | 484 | Payload= CBOR or JSON |\ Successful 485 +------------------------------------------------->| |renegotiation 486 | | |as the 487 | ACK; | |consumer 488 | Response = 2.04 CHANGED | |agrees to the 489 | Steam-info = <5-bit ID>001 | |revised 490 |<-------------------------------------------------|/ proposal. 491 : : 492 : (Streaming starts) : 494 Figure 4: Example showing successful renegotiation of streaming 495 parameters. Note the maneuvering of the Stream-info bit patterns. 497 Fig. 5 illustrates exemplary exchanges when a stream negotiation is 498 unsuccessful. The accompanied script may provide hints to the reason 499 for unsuccessful negotiations. A simple case of unsuccessful attempt 500 may be observed if the resource on the "consumer" side is not ready. 501 The exact formatting of the script is not in the scope of this 502 draft. 504 Client (Producer) Server (Consumer) 505 | | 506 | POST: CON; | 507 | URI=/video; | 508 | Stream-info = <5-bit ID>000; | 509 | Payload= CBOR or JSON |\ Unsuccessful 510 +------------------------------------------------->| |negotiation. 511 | | |The request 512 | ACK; | |is successful. 513 | Response = 2.04 CHANGED | |But consumer 514 | Steam-info = <5-bit ID>011 | |may reject 515 | Payload= CBOR or JSON | |for some 516 |<-------------------------------------------------|/ reason 517 | | mentioned in 518 Script. 520 Figure 5: Example showing unsuccessful renegotiation despite 521 successful response code against the initiation request. 523 6. Some Design Guidelines 525 6.1. Implicit Congestion Avoidance 527 The throughput and resource optimization for A-REaLiST depends 528 largely on the best-effort delivery on UDP. Despite that the 529 application designer can make A-REaLiST implicitly congestion aware 530 and proactively avoid congestion. CoAP has a basic congestion 531 avoidance mechanism which uses exponential back off to increase the 532 timeout for retransmissions. However, that works only for CON 533 messages. 535 The implicit congestion avoidance works like this: In case the 536 producer fails to successfully transfer a critical segment of a 537 frame within the MAX_TRANSMIT_SPAN as well as within MAX_RETRANSMIT 538 [RFC7252] attempts, the producer drops transmission of rest of the 539 segments in that frame and waits for the next frame to be ready. The 540 rationale is, since the critical segment is not delivered, the 541 consumer will fail to reconstruct this frame anyway. So, there is no 542 point in clogging the network with rest of the segments. 544 6.2. Considerations for Consumer-side Rendering 546 While the critical segments are delivered reliably in a sequential 547 manner, non-critical are delivered with best-effort in an open-loop 548 exchange. Also, the whole frame can be dropped to avoid congestion. 549 Hence, the application at the "consumer" end-point (server) needs to 550 deal with issues like out-of-order delivery, frame/segment loss, 551 asynchronous segment arrival. 553 The issues mentioned above have been discussed in literatures 554 [Perkins]. So the basic approach should be: Buffer till a critical 555 time to iron out the jittery, out-of-order arrival of the segments, 556 play out from the appropriate buffer at a constant rate determined 557 by the frame-rate of the video. There may be intelligent algorithms 558 to play-out with high QoE despite non-arrival of non-critical 559 segments within the play-out deadline. This draft provides the hooks 560 to create such designs. Reference architecture of the play-out 561 mechanism is provided in [Wi-UAV-Globecom]. The play-out 562 architecture leverages on the design assumption about the 'less- 563 constrained' nature of the consumer in terms of memory and 564 processor. 566 6.3. Determining the segment size 568 Size of the information segment in a CoAP message should be limited 569 by the least possible MTU for the end-to-end channel. This is to 570 ensure that there is no undesired conversation state at the lower 571 layers of the protocol stack due to uncontrolled fragmentation 572 leading to undesired explosion of traffic in the network. For IPV6 573 network, the MTU can be determined using Path MTU Discovery (PMTUD) 574 [RFC8201] which bestows the responsibility of determining the path 575 MTU on the end-points itself. 577 The size of the segment should be guided by the recommendations as 578 specified in Section 4.6 of [RFC7252]. 580 7. IANA Considerations 582 The IANA is requested to assign numbers to the three options 583 introduced in this draft for inclusion in the "CoAP Option Numbers" 584 registry as shown below. 586 +--------+--------------+-------------+ 587 | Number | Name | Reference | 588 +--------+--------------+-------------+ 589 | TBD | Stream-info | Section 4 | 590 +--------+--------------+-------------+ 591 | TBD | Time-stamp | Section 4 | 592 +--------+--------------+-------------+ 593 | TBD | Position | Section 4 | 594 +--------+--------------+-------------+ 596 8. Security Considerations 598 This draft presents no security considerations beyond those in 599 Section 11 of the base CoAP specification [RFC7252]. 601 9. References 603 9.1. Normative References 605 [RFC7252] 607 Shelby, Z., Hartke, K. and Bormann, C.,"Constrained Application 608 Protocol (CoAP)", RFC 7252, June, 2014. 610 [RFC7967] 612 Bhattacharyya, A., Bandyopadhyay, S., Pal, A., Bose, T., 613 "Constrained Application Protocol (CoAP) Option for No Server 614 Response", RFC 7967, August, 2016. 616 9.2. Informative References 618 [IOT-ISOC] 620 Rose, K., Eldridge, S., Chapin, L., "The Internet of Things: an 621 overview", Internet Society, pp.1-50, October, 2015. 623 [RFC7452] 625 Tschofenig, H., Arkko, J., McPherson, D., "Architectural 626 Considerations in Smart Object Networking", RFC 7452, March, 2015. 628 [Murphy] 630 Murphy, C., "Internet of Things: Are you underestimating video?", 631 Available online: 633 http://www.informationweek.com/bigdata/bigdataanalytics/internetofth 634 ingsareyouunderestimatingvideo/a/d-id/1269508, June, 2014. 636 [Pereira] 638 Pereira, R., Pereira, E. G., "Video Streaming Considerations for 639 Internet of Things", International Conference on Future Internet of 640 Things and Cloud, pp. 48-52, August, 2014. 642 [RFC7959] 644 Bormann, C., Shelby, Z., "Block-Wise Transfers in the Constrained 645 Application Protocol (CoAP)", RFC 7959, August, 2016. 647 [GIoTS] 649 Dey, S., Bhattacharyya, A., Mukherjee, A., "Semantic data exchange 650 between collaborative robots in fog environment: Can CoAP be a 651 choice?", Global IoTS, pp. 1-6, June, 2017. 653 [RFC2616] 655 Fielding, R., Irvine, U.C., Gettys, J., Mogul, J., Frystyk, H., 656 Masinter, L., Leach, P., Berners-Lee, T., "Hypertext Transfer 657 Protocol -- HTTP/1.1", RFC 2616, June, 1999. 659 [RFC3550] 661 Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., "RTP: A 662 Transport Protocol for Real-Time Applications", RFC 3550, July, 663 2003. 665 [Wi-UAV-Globecom] 667 Bhattacharyya, A., Agrawal, S., Rath, H., Pal, A., "Improving Live- 668 streaming Experience for Delay-sensitive IoT Applications : A 669 RESTful Approach", accepted in Globecom (Wi-UAV workshop), Dec., 670 2018. 672 [Perkins] 674 Perkins, C., "RTP: Audio and Video for the Internet", Addison- 675 Wesley, 2003. 677 [RFC8201] 678 McCann, J., et al., "Path MTU Discovery for IP version 6", RFC 8201, 679 July, 2017. 681 Authors' Addresses 683 Abhijan Bhattacharyya 684 Tata Consultancy Services Ltd. 685 Kolkata, India 687 Email: abhijan.bhattacharyya@tcs.com 689 Suvrat Agrawal 690 Tata Consultancy Services Ltd. 691 Bangalore, India 693 Email: suvrat.a@tcs.com 695 Hemant Rath 696 Tata Consultancy Services Ltd. 697 Bhubaneswar, India 699 Email: hemant.rath@tcs.com 701 Arpan Pal 702 Tata Consultancy Services Ltd. 703 Kolkata, India 705 Email: arpan.pal@tcs.com 707 Balamurali Purushothaman 708 Tata Consultancy Services Ltd. 709 Bangalore, India 711 Email: balamurali.p@tcs.com