idnits 2.17.1 draft-shi-quic-dtp-04.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 8 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (25 July 2021) is 1003 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Section 4' is mentioned on line 151, but not defined == Missing Reference: 'Section 5' is mentioned on line 245, but not defined == Unused Reference: 'RFC0768' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'RFC0793' is defined on line 701, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-20 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-20 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Y. Cui 3 Internet-Draft Z. Liu 4 Intended status: Informational H. Shi 5 Expires: 26 January 2022 J. Zhang 6 Tsinghua University 7 K. Zheng 8 W. Wang 9 Huawei 10 25 July 2021 12 Deadline-aware Transport Protocol 13 draft-shi-quic-dtp-04 15 Abstract 17 This document defines Deadline-aware Transport Protocol (DTP) to 18 provide block-based deliver-before-deadline transmission. The 19 intention of this memo is to describe a mechanism to fulfill 20 unreliable transmission based on QUIC as well as how to enhance 21 timeliness of data delivery. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 26 January 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Design of DTP . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Architecture of DTP . . . . . . . . . . . . . . . . . . . 5 62 3.3. Deadline-aware Scheduler . . . . . . . . . . . . . . . . 7 63 3.4. Deadline-aware Redundancy . . . . . . . . . . . . . . . . 8 64 3.5. Loss Detection and Congestion Control . . . . . . . . . . 9 65 4. Extension of QUIC . . . . . . . . . . . . . . . . . . . . . . 10 66 4.1. New Frame: BLOCK_INFO Frame . . . . . . . . . . . . . . . 10 67 4.2. Adjusted QUIC Frame: Timestamped ACK Frame . . . . . . . 11 68 4.3. Redundancy Packet . . . . . . . . . . . . . . . . . . . . 11 69 5. DTP Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.1. Block Based Real Time Application . . . . . . . . . . . . 12 71 5.2. API of DTP . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.2.1. Data Transmission Functions . . . . . . . . . . . . . 13 73 5.2.2. Feedback Functions . . . . . . . . . . . . . . . . . 15 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 8. Normative References . . . . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 Many emerging applications have the deadline requirement for their 82 data transmission. However, current transport layer protocol like 83 TCP [RFC0793]and UDP [RFC0768]only provide primitive connection 84 establishment and data sending service. This document proposes a new 85 transport protocol atop QUIC [QUIC]to deliver application data before 86 end-to-end deadline. 88 1.1. Conventions 90 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 91 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 92 they appear in this document, are to be interpreted as described in 93 [RFC2119]. 95 2. Motivation 97 Many applications such as real-time media and online multiplayer 98 gaming have requirements for their data to arrive before a certain 99 time i.e., deadline. For example, the end-to-end delay of video 100 conferencing system should be below human perception (about 100ms) to 101 enable smooth interaction among participants. For Online multiplayer 102 gaming, the server aggregates each player's actions every 60ms and 103 distributes these information to other players so that each player's 104 state can be kept in sync. Data missing the deadline is useless 105 since it will be overwrote by the new data. 107 These real-time applications have following common features: 109 * They tend to generate and process the data in block fashion. Each 110 block is a minimal data processing unit. Missing a single byte of 111 data will make the block useless. For example, video/audio 112 encoder produces the encoded streams as a series of block(I,B,P 113 frame or GOP). Decoder consumes the frame into the full image. 114 For online games, the player's commands and world state will be 115 bundled together as a message. 117 * They will continuously generate new data. Different from web 118 browsing or file syncing, real-time applications like video 119 conferencing and online multiplayer gaming have uninterruptedly 120 interactions with users, and each interaction requires a bunch of 121 new data to be transmitted. 123 * They prefer the timeliness of data instead of reliability since 124 data missing deadline are useless to application and will be 125 obsoleted by newer data. For example in multiplayer online games, 126 the gaming server will broadcast the latest player states to every 127 client, and the old information does not matter if it can not be 128 delivered in time. So the meaningful deadline of the application 129 is actually the block completion time i.e., the time between when 130 the block is generated at sender and when the block is submitted 131 to application at receiver. 133 However, current transport layer protocols lack support for block- 134 based deadline delivery. TCP guarantees reliability so it will waste 135 network resource to transmit stale data and cause fresh data to miss 136 its deadline. UDP is unreliable but it doesn't drop data according 137 to deadline, all data have the same chance to be dropped indeed. 138 QUIC makes several improvements and introduces Stream Prioritization 139 [QUIC]to enhance application performance, but prioritization is not 140 enough for enhancing timeliness. 142 Insufficiency of existing transport layer forces applications to 143 design their own customized and complex mechanism to meet the 144 deadline requirement. For example, the video bitrate auto-adjustment 145 in most streaming applications. But this is a disruption to the 146 Layered Internet Architecture, forcing applications to worry about 147 network conditions. 149 This document proposes Deadline-aware Transport Protocol (DTP) to 150 provide deliver-before-deadline transmission. DTP is implemented as 151 an extension of QUIC (Refer to [Section 4]) because QUIC provides 152 many useful features including full encryption, user space 153 deployment, zero-RTT handshake and multiplexing without head-of-line 154 blocking. 156 3. Design of DTP 158 The key insight of DTP is that these real-time applications usually 159 have multiple blocks (As shown in Figure 1 below) to be transferred 160 simultaneously and these blocks have diverse impact on user 161 experience(denoted as priority). For example, audio data is more 162 important than video stream in video conferencing. Central region is 163 more important than surrounding region in 360 degree video. 164 Foreground object rendering is more important than the background 165 scene in mobile VR offloading. 167 The priority difference among multiple blocks makes it possible to 168 drop low priority data to improve timeliness of high priority data 169 delivery, which can enhance the overall QoE if resources allocated to 170 blocks are correctly prioritized. In this section, we describe the 171 mechanism which enables DTP to leverage that insight. 173 3.1. Abstraction 175 DTP provides block-based data abstraction for application. 176 Application MUST attach metadata along with the data block to 177 facilitate the scheduling decision, those metadata include: 179 * Each block has a deadline requirement, meaning if the block cannot 180 arrive before the deadline, then the whole block may become 181 useless because it will be overwrote by newer blocks. The 182 application can mark the deadline timestamp indicating the 183 deadline of its completion time. In the API of DTP, the deadline 184 argument represents the desired block completion time in ms. 186 * Each block has its own importance to the user experience. The 187 application can assign each block a priority to indicate the 188 importance of the block. The lower the priority value, the more 189 important the block. The priority argument also indicates the 190 reliability requirement of the block. The higher priority, the 191 less likely the block will be dropped by sender. 193 3.2. Architecture of DTP 195 The sender side architecture is shown in Figure 1: 197 +-------------+ 198 | | 199 | Application | 200 | | 201 +-------------+ 202 | 203 | 204 V 205 +------------------------------------------------------------------------+ 206 | Block 0 Block 1 Block n | 207 | +--------+----------+ +--------+----------+ +--------+----------+ | 208 | |Metadata|Data Block| |Metadata|Data Block| ... |Metadata|Data Block| | 209 | +--------+----------+ +--------+----------+ +--------+----------+ | 210 | | 211 | (Metadata includes Deadline and Priority) | 212 +------------------------------------------------------------------------+ 213 | 214 | 215 v 216 +-------------+ 217 | | 218 | Scheduler | 219 | | 220 +-------------+ 221 | 222 | 223 v 224 +-------------+ 225 | | 226 | Redundancy | 227 | | 228 +-------------+ 229 | 230 | 231 v 232 +-------------+ 233 | | 234 | Congestion | 235 | Control | 236 +-------------+ 237 | 238 v 239 Figure 1: The Architecture of DTP 241 In receiver side, the transport layer will receive data and 242 reassemble the block. The process is symmetric with the sender side. 243 It first goes through packet parsing and redundancy processing 244 module. Transport layer also keeps track of the deadline of each 245 block. When receiver calls RECV function (Refer to [Section 5]), the 246 transport layer returns the received in-ordered data to the 247 application. 249 3.3. Deadline-aware Scheduler 251 The scheduler will pick the blocks to send and drop stale blocks when 252 the buffer is limited. This section describes the algorithm of DTP 253 scheduler. 255 Scheduler of DTP takes into account many factors when picking blocks 256 in sender buffer to send. The goal of the scheduler is to deliver as 257 much as high priority data before the deadline and drop obsolete or 258 low-priority blocks. To achieve this, the scheduler utilizes both 259 bandwidth and RTT measurement provided by the congestion control 260 module and the metadata of blocks provided by the application to 261 estimate the block completion time. The scheduler will run each time 262 ACK is received or the application pushes the data. 264 A simple algorithm which only considers priority cannot get optimal 265 result in transmitting deadline-required data. Suppose the bandwidth 266 reduces and the scheduler chooses not to send the low priority block. 267 Then the bandwidth is restored. The data block with lower priority 268 is closer to the deadline than the high priority block. If in this 269 round the scheduler still chooses to send the high priority block, 270 then the low priority block may miss the deadline next round and 271 become useless. In some cases, the scheduler can choose to send a 272 low priority block because it's more urgent. But it should do so 273 without causing the high priority stream missing the deadline. This 274 example reveals a fundamental conflict between the application 275 specified priority and deadline implicated priority. DTP needs to 276 take both priorities into consideration when scheduling blocks. 278 DTP will combine all these factors to calculate real priority of each 279 block. Then the scheduler just picks the block with the highest real 280 priority. Scheduler of DTP will calculate the block remaining 281 transmission time and then compare it to the deadline. The closer to 282 the deadline, the higher real priority. And higher application 283 specified priority will also result in higher real priority. In this 284 way, the scheduler can take both approaching deadline and 285 application-specified priority into account. Blocks which are 286 severely overdue can be dropped accordingly. 288 3.4. Deadline-aware Redundancy 290 After the scheduler pick the block to send, the packetizer will break 291 the block into packet streams. Those packet streams will go through 292 the redundancy module. When the link is lossy and deadline is tight, 293 retransmission will cause the block missing the deadline. Redundancy 294 module has the ability of sending redundancy (like FEC Repair 295 Symbols) along with the data that will help to recover the data 296 packets (like FEC Source Symbols), this can avoid retransmission. 298 We use unencrypted DTP packets as input to Redundancy Module because 299 the loss of a DTP packet exactly corresponds to the loss of one 300 Redundancy Packet. And to perform the coding and decoding with 301 packets of different sizes, some packets may need to be padded with 302 PADDING Frame. The present design of Redundancy Module follows the 303 FEC Framework specified in [arXiv:1809.04822]. Figure 2 illustrates 304 this framework: 306 | 307 | 308 v 309 +-------------+ 310 | | 311 | DTP | 312 | Scheduler | 313 | | 314 +------+------+ 315 | 316 (1)|DTP Packets 317 +----------|-------------------------------------------+ 318 | v | 319 | +-------+------+ +------------+ | 320 | | | (2)DTP Payload | | | DTP 321 | | Redundancy |------------------> | Redundancy | | Redundancy 322 | | Packtizing &|<------------------ | Scheme | | Module 323 | | Grouping | (2)Redundancy Data | | | 324 | +-------+------+ +------------+ | 325 | | | 326 +----------|-------------------------------------------+ 327 (3)|Redundancy 328 |Packets 329 | 330 v 331 Figure 2: DTP Redundancy Module 333 Figure 2 above shows the mechanism of how the Deadline-aware 334 Redundancy module works. (1) Redundancy Module first receives the 335 unencrypted DTP packets from scheduler. (2) The Redundancy Scheme use 336 DTP Payload (similar to FEC Repair Symbols) to generate Redundancy 337 Data (similar to FEC Source Symbols). (3) Redundancy-protected DTP 338 Packets and Redundancy Data will be packtized and grouped. 339 Redundancy Packtizing and Grouping Part will generate FEC Payload 340 INFO (Figure 5) and attach it to the DTP Packets and Redundancy Data, 341 generating Redundancy Packets (a Redundancy Packet with the header 342 shown in Figure 5). Once the protocol receives the Repair Symbols, 343 they are sent to the receiver through the FEC Packets. At the 344 receiver-side, the received Redundancy Packets can be processed 345 immediately. The Redundancy Data is reconstituted from the 346 Redundancy Packtizing and Grouping and passed to the underlying 347 Redundancy Scheme to recover the lost DTP Packets. 349 Although Redundancy Module allows recovering lost packets without 350 waiting for retransmissions, it consumes more bandwidth than a 351 regular, non-Redundancy-protected transmission. In order to avoid 352 spending additional bandwidth when it is not needed, design of 353 Redundancy MUST allow defining which DTP packets should be considered 354 as Redundancy Packets. Currently we use a F flag from DTP Packet 355 Header to indicate whether a packet is Redundancy-protected or not. 356 The format of header will be described in [Section 4.3] later. 358 The Redundancy Data generated in Redundancy module MUST be 359 distinguished from application data payload. Redundancy Data should 360 not be transferred to the application upon reception, they are indeed 361 generated by and for the Redundancy Scheme used by the transport 362 protocol. We use Redundancy Packet to transmit Redundancy Data 363 [Section 4.3]. 365 There are multiple Redundancy Scheme candidates. During the 366 handshake process, a scheme will be negotiated for the DTP session, 367 just like encryption scheme negotiation. Currently DTP specifically 368 chooses Reed-Solomon FEC Scheme as described in [arXiv:1809.04822]. 370 3.5. Loss Detection and Congestion Control 372 This document reuses the congestion control module defined in QUIC 373 [QUIC]. Congestion control module is responsible to send packets, 374 collects ACK and do packet loss detection. Then it will put the lost 375 data back to the retransmission queue of each block. Congestion 376 control module is also responsible to monitor the network status and 377 report the network condition such as bandwidth and RTT to scheduler. 379 4. Extension of QUIC 381 DTP is implemented as an extension of QUIC by mapping QUIC stream to 382 DTP block one to one. In that way, DTP can reuse the QUIC stream 383 cancellation mechanism to drop the stale block during transmission. 384 And DTP can also utilize the max stream data size defined by QUIC to 385 negotiate its max block size. Besides, the block id of DTP can also 386 be mapped to QUIC stream id without breaking the QUIC stream id 387 semantic. 389 DTP endpoints communicate by exchanging packets. And the payload of 390 DTP packets, consists of a sequence of complete frames. As defined 391 in [QUIC], each frame begins with a Frame Type, indicating its type, 392 followed by additional type-dependent fields. Besides the many frame 393 types defined in Section 12.4 of [QUIC], DTP introduces BLOCK_INFO 394 Frame to support timeliness data transmission. And DTP also makes 395 adjustment on QUIC ACK Frame. Another extension is introducing FEC 396 packet to support FEC. 398 4.1. New Frame: BLOCK_INFO Frame 400 DTP adds a BLOCK_INFO frame (type=0x20) in the front of each block to 401 inform scheduler of Block Size, Block Priority and Block Deadline. 402 These parameters can be used to do block scheduling. The BLOCK_INFO 403 frame is as follows: 405 0 1 2 3 406 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Stream ID (i) ... 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Block Size (i) ... 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Block Priority (i) ... 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Block Deadline (i) ... 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Figure 3: BLOCK_INFO Frame Format 419 * Stream ID: A variable-length integer indicating the stream ID of 420 the stream. 422 * Block Size: A variable-length integer indicating the size of the 423 block. 425 * Block Priority: A variable-length integer indicating the priority 426 of the block. 428 * Block Deadline: A variable-length integer indicating the required 429 transimission deadline. 431 4.2. Adjusted QUIC Frame: Timestamped ACK Frame 433 DTP add a new Time Stamp Parameter to QUIC ACK Frame. Timestamped 434 ACK frames are sent by reveiver to inform senders of the time when 435 the packet the peer is acknowledging is received and processed. ACK 436 mechanism of DTP is almost the same with QUIC. The format of the 437 Timestamped ACK frames is similar to that of the standard ACK Frames 438 defined in section 19.3 of [QUIC]: 440 0 1 2 3 441 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Largest Acknowledged (i) ... 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Time Stamp (i) ... 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | ACK Delay (i) ... 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | ACK Range Count (i) ... 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | First ACK Range (i) ... 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | ACK Ranges (i) ... 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | [ECN Counts] ... 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 4: Timestamped ACK Frame Format 460 Using this time stamp parameter we can calculate whether the prior 461 blocks transmitted missing deadline or not, and we can also calculate 462 the block completion rate before deadline. 464 4.3. Redundancy Packet 466 We use a F Flags in DTP Packet to distinguish which DTP packets is 467 Redundancy-protected or not. Figure 5 shows the Redundancy Packet 468 Format. If the flag is set, the Redundancy Group ID, m, n, index 469 field is appended to the header. They are used by the Redundancy 470 Scheme(Forward-Error-Correction) to identify the redundancy-protected 471 data and communicate information about the encoding and decoding 472 procedures to the receiver-side Redundancy Scheme. 474 0 1 2 3 475 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 476 +-+-+-+-+-+-+-+-+ 477 |F| Flags(7) | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 ... 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Redundancy Group ID (i)(if F set) ... 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | m (i)(if F set) ... 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | n (i)(if F set) ... 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | index (i)(if F set) ... 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Payload (i) ... 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Figure 5: Redundancy Packet Format 494 * F: A flag indicating whether this DTP packets is FEC-protected or 495 not. 497 * Redundancy Group ID: A variable-length integer indicating the id 498 of the redundancy group which the packet belongs to. 500 * m: A variable-length integer indicating the number of original 501 packets of the redundancy group. 503 * n: A variable-length integer indicating the number of redundancy 504 packets of the redundancy group. 506 * index: A variable-length integer indicating the location of the 507 packet inside the redundancy group. 509 * Payload: The payload of the Redundancy Packet, containing DTP 510 Payload or Redundancy Data. 512 5. DTP Use Cases 514 5.1. Block Based Real Time Application 516 DTP can provide deliver-before-deadline service for Block Based Real 517 Time Applications. Applications like real-time media and online 518 multiplayer gaming have deadline requirements for their data 519 transimission. These application also tend to generate and process 520 the data in block fashion, for example, video/audio encoder produces 521 the encoded streams as a series of block (I,B,P frame or GOP). And 522 these real-time applications usually have multiple blocks (As shown 523 in Figure 1) to be transferred simultaneously. DTP can optimize the 524 data transmission of these applications by scheduling which block to 525 be sent first. And Redundancy Module of DTP can reduce 526 retransmission delay. 528 5.2. API of DTP 530 DTP extends the send socket API to let application attach metadata 531 along with the data block, and the API of DTP is structured as 532 follows: 534 5.2.1. Data Transmission Functions 536 Send 538 Format: SEND(connection id, buffer address, byte count, block id, 539 block deadline, block priority) -> byte count 541 The return value of SEND is the continuous bytes count which is 542 successfully written. If the transport layer buffer is limited or 543 the flow control limit of the block is reached, application needs 544 to call SEND again. 546 Mandatory attributes: 548 - connection id - local connection name of an indicated 549 connection. 551 - buffer address - the location where the block to be transmitted 552 is stored. 554 - byte count - the size of the block data in number of bytes. 556 - block id - the identity of the block. 558 - block deadline - deadline of the block. 560 - block priority - priority of the block. 562 Update 564 Format: UPDATE(connection id, block id, block deadline, block 565 priority) -> result 566 The UPDATE function is used to update the metadata of the block. 567 The return value of UPDATE function indicates the success of the 568 action. It will return success code if succeeds, and error code 569 if fails. 571 Mandatory attributes: 573 - connection id - local connection name of an indicated 574 connection. 576 - block id - the identity of the block. 578 - block deadline - new deadline of the block. 580 - block priority - new priority of the block. 582 Retreat 584 Format: RETREAT(connection id, block id) -> result 586 The RETREAT function is used to cancel the block. The return 587 value of RETREAT function indicates the success of the action. It 588 will return success code if succeeds, and error code if fails. 590 Mandatory attributes: 592 - connection id - local connection name of an indicated 593 connection. 595 - block id - the identity of the block. 597 Receive 599 Format: RECV(connection id, buffer address, byte count, [,block 600 id]) -> byte count, fin flag, [,block id] 602 The RECV function shall read the first block in-queue into the 603 buffer specified, if there is one available. The return value of 604 RECV is the number of continuous bytes which is successfully read, 605 and fin flag to indicate the ending of the block. If the block is 606 cancelled, the RECV function will return error code 607 BLOCK_CANCELLED. It will also returns the block id on which it 608 receives if application does not specify it. 610 If the block size specified in the RECV function is smaller than 611 the size of the receiving block, then the block will be partial 612 copied(indicated by the fin flag). Next time RECV function is 613 called, the remaining block will be copied, and the id will be the 614 same. This fragmentation will give extra burden to applications. 615 To avoid the fragmentation, sender and receiver can negotiate a 616 max block size when handshaking. 618 Mandatory attributes: 620 - connection id - local connection name of an indicated 621 connection. 623 - buffer address - the location where the block received is 624 stored. 626 - byte count - the size of the block data in number of bytes. 628 Optional attributes: 630 - block id - to indicate which block to receive the data on. 632 5.2.2. Feedback Functions 634 on_dropped 636 Format: ON_DROPPED(connection id) -> block id, deadline, priority, 637 goodbytes 639 The ON_DROPPED function is called when a block is dropped. The 640 metadata of the dropped block such as block id, deadline, priority 641 is attached. The number of bytes delivered before its 642 deadline(goodbytes) is returned. 644 Mandatory attributes: 646 - connection id - local connection name of an indicated 647 connection. 649 on_delivered 651 Format: ON_DELIVERED(connection id) -> block id, deadline, 652 priority, delta, goodbytes 654 The ON_DELIVERED function is called when a block is delivered. 655 The metadata of the delivered block such as block id, deadline, 656 priority is attached. The number of bytes delivered before its 657 deadline (goodbytes) and the difference between the block 658 completion time and the deadline (delta) are returned. 660 Mandatory attributes: 662 - connection id - local connection name of an indicated 663 connection. 665 All these functions mentioned above are running in asynchronous mode. 666 An application can use various event driven framework to call those 667 functions. 669 6. IANA Considerations 671 This document has no actions for IANA. 673 7. Security Considerations 675 See the security considerations in [QUIC]and [QUIC-TLS]; the block- 676 based data of DTP shares the same security properties as the data 677 transmitted within a QUIC connection 679 8. Normative References 681 [arXiv_1809.04822] 682 Michel, F., Coninck, Q., and O. Bonaventure, "Adding 683 Forward Erasure Correction to QUIC", 13 September 2018, 684 . 686 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 687 and Secure Transport", Work in Progress, Internet-Draft, 688 draft-ietf-quic-transport-20, 23 April 2019, 689 . 692 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 693 Work in Progress, Internet-Draft, draft-ietf-quic-tls-20, 694 23 April 2019, . 697 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 698 DOI 10.17487/RFC0768, August 1980, 699 . 701 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 702 RFC 793, DOI 10.17487/RFC0793, September 1981, 703 . 705 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 706 Requirement Levels", BCP 14, RFC 2119, 707 DOI 10.17487/RFC2119, March 1997, 708 . 710 Authors' Addresses 712 Yong Cui 713 Tsinghua University 714 30 Shuangqing Rd 715 Beijing 716 China 718 Email: cuiyong@tsinghua.edu.cn 720 Zhiwen Liu 721 Tsinghua University 722 30 Shuangqing Rd 723 Beijing 724 China 726 Email: liu-zw20@mails.tsinghua.edu.cn 728 Hang Shi 729 Tsinghua University 730 30 Shuangqing Rd 731 Beijing 732 China 734 Email: shi-h15@mails.tsinghua.edu.cn 736 Jie Zhang 737 Tsinghua University 738 30 Shuangqing Rd 739 Beijing 740 China 742 Email: zhangjie19@mails.tsinghua.edu.cn 744 Kai Zheng 745 Huawei 747 Email: kai.zheng@huawei.com 749 Wei Wang 750 Huawei 752 Email: wangwei375@huawei.com