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