idnits 2.17.1 draft-shi-quic-dtp-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 : ---------------------------------------------------------------------------- ** 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 (July 25, 2020) is 1370 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Section 4' is mentioned on line 152, but not defined == Missing Reference: 'Section 5' is mentioned on line 246, but not defined == 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 (~~), 6 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: January 26, 2021 J. Zhang 6 Tsinghua University 7 K. Zheng 8 W. Wang 9 Huawei 10 July 25, 2020 12 Deadline-aware Transport Protocol 13 draft-shi-quic-dtp-02 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 January 26, 2021. 40 Copyright Notice 42 Copyright (c) 2020 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 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Design of DTP . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Architecture of DTP . . . . . . . . . . . . . . . . . . . 5 63 3.3. Deadline-aware Scheduler . . . . . . . . . . . . . . . . 7 64 3.4. Deadline-aware Redundancy . . . . . . . . . . . . . . . . 7 65 3.5. Loss Detection and Congestion Control . . . . . . . . . . 9 66 4. Extension of QUIC . . . . . . . . . . . . . . . . . . . . . . 9 67 4.1. New Frame: BLOCK_INFO Frame . . . . . . . . . . . . . . . 10 68 4.2. Adjusted QUIC Frame: Timestamped ACK Frame . . . . . . . 10 69 4.3. Redundancy Packet . . . . . . . . . . . . . . . . . . . . 11 70 5. DTP Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.1. Block Based Real Time Application . . . . . . . . . . . . 12 72 5.2. API of DTP . . . . . . . . . . . . . . . . . . . . . . . 12 73 5.2.1. Data Transmission Functions . . . . . . . . . . . . . 13 74 5.2.2. Feedback Functions . . . . . . . . . . . . . . . . . 15 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 Many emerging applications have the deadline requirement for their 83 data transmission. However, current transport layer protocol like 84 TCP [RFC0793] and UDP [RFC0768] only provide primitive connection 85 establishment and data sending service. This document proposes a new 86 transport protocol atop QUIC [QUIC] to deliver application data 87 before end-to-end deadline. 89 1.1. Conventions 91 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 92 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 93 they appear in this document, are to be interpreted as described in 94 [RFC2119]. 96 2. Motivation 98 Many applications such as real-time media and online multiplayer 99 gaming have requirements for their data to arrive before a certain 100 time i.e., deadline. For example, the end-to-end delay of video 101 conferencing system should be below human perception (about 100ms) to 102 enable smooth interaction among participants. For Online multiplayer 103 gaming, the server aggregates each player's actions every 60ms and 104 distributes these information to other players so that each player's 105 state can be kept in sync. Data missing the deadline is useless 106 since it will be overwrote by the new data. 108 These real-time applications have following common features: 110 o They tend to generate and process the data in block fashion. Each 111 block is a minimal data processing unit. Missing a single byte of 112 data will make the block useless. For example, video/audio 113 encoder produces the encoded streams as a series of block(I,B,P 114 frame or GOP). Decoder consumes the frame into the full image. 115 For online games, the player's commands and world state will be 116 bundled together as a message. 118 o They will continuously generate new data. Different from web 119 browsing or file syncing, real-time applications like video 120 conferencing and online multiplayer gaming have uninterruptedly 121 interactions with users, and each interaction requires a bunch of 122 new data to be transmitted. 124 o They prefer the timeliness of data instead of reliability since 125 data missing deadline are useless to application and will be 126 obsoleted by newer data. For example in multiplayer online games, 127 the gaming server will broadcast the latest player states to every 128 client, and the old information does not matter if it can not be 129 delivered in time. So the meaningful deadline of the application 130 is actually the block completion time i.e., the time between when 131 the block is generated at sender and when the block is submitted 132 to application at receiver. 134 However, current transport layer protocols lack support for block- 135 based deadline delivery. TCP guarantees reliability so it will waste 136 network resource to transmit stale data and cause fresh data to miss 137 its deadline. UDP is unreliable but it doesn't drop data according 138 to deadline, all data have the same chance to be dropped indeed. 139 QUIC makes several improvements and introduces Stream Prioritization 140 [QUIC] to enhance application performance, but prioritization is not 141 enough for enhancing timeliness. 143 Insufficiency of existing transport layer forces applications to 144 design their own customized and complex mechanism to meet the 145 deadline requirement. For example, the video bitrate auto-adjustment 146 in most streaming applications. But this is a disruption to the 147 Layered Internet Architecture, forcing applications to worry about 148 network conditions. 150 This document proposes Deadline-aware Transport Protocol (DTP) to 151 provide deliver-before-deadline transmission. DTP is implemented as 152 an extension of QUIC (Refer to [Section 4]) because QUIC provides 153 many useful features including full encryption, user space 154 deployment, zero-RTT handshake and multiplexing without head-of-line 155 blocking. 157 3. Design of DTP 159 The key insight of DTP is that these real-time applications usually 160 have multiple blocks (As shown in Figure 1 below) to be transferred 161 simultaneously and these blocks have diverse impact on user 162 experience(denoted as priority). For example, audio data is more 163 important than video stream in video conferencing. Central region is 164 more important than surrounding region in 360 degree video. 165 Foreground object rendering is more important than the background 166 scene in mobile VR offloading. 168 The priority difference among multiple blocks makes it possible to 169 drop low priority data to improve timeliness of high priority data 170 delivery, which can enhance the overall QoE if resources allocated to 171 blocks are correctly prioritized. In this section, we describe the 172 mechanism which enables DTP to leverage that insight. 174 3.1. Abstraction 176 DTP provides block-based data abstraction for application. 177 Application MUST attach metadata along with the data block to 178 facilitate the scheduling decision, those metadata include: 180 o Each block has a deadline requirement, meaning if the block cannot 181 arrive before the deadline, then the whole block may become 182 useless because it will be overwrote by newer blocks. The 183 application can mark the deadline timestamp indicating the 184 deadline of its completion time. In the API of DTP, the deadline 185 argument represents the desired block completion time in ms. 187 o Each block has its own importance to the user experience. The 188 application can assign each block a priority to indicate the 189 importance of the block. The lower the priority value, the more 190 important the block. The priority argument also indicates the 191 reliability requirement of the block. The higher priority, the 192 less likely the block will be dropped by sender. 194 3.2. Architecture of DTP 196 The sender side architecture is shown in Figure 1: 198 +-------------+ 199 | | 200 | Application | 201 | | 202 +-------------+ 203 | 204 | 205 V 206 +------------------------------------------------------------------------+ 207 | Block 0 Block 1 Block n | 208 | +--------+----------+ +--------+----------+ +--------+----------+ | 209 | |Metadata|Data Block| |Metadata|Data Block| ... |Metadata|Data Block| | 210 | +--------+----------+ +--------+----------+ +--------+----------+ | 211 | | 212 | (Metadata includes Deadline and Priority) | 213 +------------------------------------------------------------------------+ 214 | 215 | 216 v 217 +-------------+ 218 | | 219 | Scheduler | 220 | | 221 +-------------+ 222 | 223 | 224 v 225 +-------------+ 226 | | 227 | Redundancy | 228 | Encoder | 229 +-------------+ 230 | 231 | 232 v 233 +-------------+ 234 | | 235 | Congestion | 236 | Control | 237 +-------------+ 238 | 239 v 240 Figure 1: The Architecture of DTP 242 In receiver side, the transport layer will receive data and 243 reassemble the block. The process is symmetric with the sender side. 244 It first goes through packet parsing and redundancy processing 245 module. Transport layer also keeps track of the deadline of each 246 block. When receiver calls RECV function (Refer to [Section 5]), the 247 transport layer returns the received in-ordered data to the 248 application. 250 3.3. Deadline-aware Scheduler 252 The scheduler will pick the blocks to send and drop stale blocks when 253 the buffer is limited. This section describes the algorithm of DTP 254 scheduler. 256 Scheduler of DTP takes into account many factors when picking blocks 257 in sender buffer to send. The goal of the scheduler is to deliver as 258 much as high priority data before the deadline and drop obsolete or 259 low-priority blocks. To achieve this, the scheduler utilizes both 260 bandwidth and RTT measurement provided by the congestion control 261 module and the metadata of blocks provided by the application to 262 estimate the block completion time. The scheduler will run each time 263 ACK is received or the application pushes the data. 265 A simple algorithm which only considers priority cannot get optimal 266 result in transmitting deadline-required data. Suppose the bandwidth 267 reduces and the scheduler chooses not to send the low priority block. 268 Then the bandwidth is restored. The data block with lower priority 269 is closer to the deadline than the high priority block. If in this 270 round the scheduler still chooses to send the high priority block, 271 then the low priority block may miss the deadline next round and 272 become useless. In some cases, the scheduler can choose to send a 273 low priority block because it's more urgent. But it should do so 274 without causing the high priority stream missing the deadline. This 275 example reveals a fundamental conflict between the application 276 specified priority and deadline implicated priority. DTP needs to 277 take both priorities into consideration when scheduling blocks. 279 DTP will combine all these factors to calculate real priority of each 280 block. Then the scheduler just picks the block with the highest real 281 priority. Scheduler of DTP will calculate the block remaining 282 transmission time and then compare it to the deadline. The closer to 283 the deadline, the higher real priority. And higher application 284 specified priority will also result in higher real priority. In this 285 way, the scheduler can take both approaching deadline and 286 application-specified priority into account. Blocks which are 287 severely overdue can be dropped accordingly. 289 3.4. Deadline-aware Redundancy 291 After the scheduler pick the block to send, the packetizer will break 292 the block into packet streams. Those packet streams will go through 293 the redundancy module. When the link is lossy and deadline is tight, 294 retransmission will cause the block missing the deadline. Redundancy 295 module has the ability of sending redundancy (like FEC Repair 296 Symbols) along with the data that will help to recover the data 297 packets (like FEC Source Symbols), this can avoid retransmission. 299 We use unencrypted DTP packets as input to Redundancy Module because 300 the loss of a DTP packet exactly corresponds to the loss of one 301 Redundancy Packet. And to perform the coding and decoding with 302 packets of different sizes, some packets may need to be padded with 303 PADDING Frame. The present design of Redundancy Module follows the 304 FEC Framework specified in [arXiv:1809.04822]. Figure 2 illustrates 305 this framework: 307 | 308 | 309 v 310 +-------------+ 311 | | 312 | DTP | 313 | Scheduler | 314 | | 315 +------+------+ 316 | 317 (1)|DTP Packets 318 +----------|-------------------------------------------+ 319 | v | 320 | +-------+------+ +------------+ | 321 | | | (2)DTP Payload | | | DTP 322 | | Redundancy |------------------> | Redundancy | | Redundancy 323 | | Packtizing &|<------------------ | Scheme | | Module 324 | | Grouping | (2)Redundancy Data | | | 325 | +-------+------+ +------------+ | 326 | | | 327 +----------|-------------------------------------------+ 328 (3)|Redundancy 329 |Packets 330 | 331 v 332 Figure 2: DTP Redundancy Module 334 Figure 2 above shows the mechanism of how the Deadline-aware 335 Redundancy module works. (1) Redundancy Module first receives the 336 unencrypted DTP packets from scheduler. (2) The Redundancy Scheme use 337 DTP Payload (similar to FEC Repair Symbols) to generate Redundancy 338 Data (similar to FEC Source Symbols). (3) Redundancy-protected DTP 339 Packets and Redundancy Data will be packtized and grouped. 340 Redundancy Packtizing and Grouping Part will generate FEC Payload 341 INFO (Figure 5) and attach it to the DTP Packets and Redundancy Data, 342 generating Redundancy Packets (a Redundancy Packet with the header 343 shown in Figure 5). Once the protocol receives the Repair Symbols, 344 they are sent to the receiver through the FEC Packets. At the 345 receiver-side, the received Redundancy Packets can be processed 346 immediately. The Redundancy Data is reconstituted from the 347 Redundancy Packtizing and Grouping and passed to the underlying 348 Redundancy Scheme to recover the lost DTP Packets. 350 Although Redundancy Module allows recovering lost packets without 351 waiting for retransmissions, it consumes more bandwidth than a 352 regular, non-Redundancy-protected transmission. In order to avoid 353 spending additional bandwidth when it is not needed, design of 354 Redundancy MUST allow defining which DTP packets should be considered 355 as Redundancy Packets. Currently we use a F flag from DTP Packet 356 Header to indicate whether a packet is Redundancy-protected or not. 357 The format of header will be described in [Section 4.3] later. 359 The Redundancy Data generated in Redundancy module MUST be 360 distinguished from application data payload. Redundancy Data should 361 not be transferred to the application upon reception, they are indeed 362 generated by and for the Redundancy Scheme used by the transport 363 protocol. We use Redundancy Packet to transmit Redundancy Data 364 [Section 4.3]. 366 There are multiple Redundancy Scheme candidates. During the 367 handshake process, a scheme will be negotiated for the DTP session, 368 just like encryption scheme negotiation. Currently DTP specifically 369 chooses Reed-Solomon FEC Scheme as described in [arXiv:1809.04822]. 371 3.5. Loss Detection and Congestion Control 373 This document reuses the congestion control module defined in QUIC 374 [QUIC]. Congestion control module is responsible to send packets, 375 collects ACK and do packet loss detection. Then it will put the lost 376 data back to the retransmission queue of each block. Congestion 377 control module is also responsible to monitor the network status and 378 report the network condition such as bandwidth and RTT to scheduler. 380 4. Extension of QUIC 382 DTP is implemented as an extension of QUIC by mapping QUIC stream to 383 DTP block one to one. In that way, DTP can reuse the QUIC stream 384 cancellation mechanism to drop the stale block during transmission. 385 And DTP can also utilize the max stream data size defined by QUIC to 386 negotiate its max block size. Besides, the block id of DTP can also 387 be mapped to QUIC stream id without breaking the QUIC stream id 388 semantic. 390 DTP endpoints communicate by exchanging packets. And the payload of 391 DTP packets, consists of a sequence of complete frames. As defined 392 in [QUIC], each frame begins with a Frame Type, indicating its type, 393 followed by additional type-dependent fields. Besides the many frame 394 types defined in Section 12.4 of [QUIC], DTP introduces BLOCK_INFO 395 Frame to support timeliness data transmission. And DTP also makes 396 adjustment on QUIC ACK Frame. Another extension is introducing FEC 397 packet to support FEC. 399 4.1. New Frame: BLOCK_INFO Frame 401 DTP adds a BLOCK_INFO frame (type=0x20) in the front of each block to 402 inform scheduler of Block Size, Block Priority and Block Deadline. 403 These parameters can be used to do block scheduling. The BLOCK_INFO 404 frame is as follows: 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Stream ID (i) ... 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Block Size (i) ... 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Block Priority (i) ... 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Block Deadline (i) ... 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 3: BLOCK_INFO Frame Format 420 o Stream ID: A variable-length integer indicating the stream ID of 421 the stream. 423 o Block Size: A variable-length integer indicating the size of the 424 block. 426 o Block Priority: A variable-length integer indicating the priority 427 of the block. 429 o Block Deadline: A variable-length integer indicating the required 430 transimission deadline. 432 4.2. Adjusted QUIC Frame: Timestamped ACK Frame 434 DTP add a new Time Stamp Parameter to QUIC ACK Frame. Timestamped 435 ACK frames are sent by reveiver to inform senders of the time when 436 the packet the peer is acknowledging is received and processed. ACK 437 mechanism of DTP is almost the same with QUIC. The format of the 438 Timestamped ACK frames is similar to that of the standard ACK Frames 439 defined in section 19.3 of [QUIC]: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Largest Acknowledged (i) ... 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Time Stamp (i) ... 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | ACK Delay (i) ... 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | ACK Range Count (i) ... 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | First ACK Range (i) ... 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | ACK Ranges (i) ... 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | [ECN Counts] ... 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Figure 4: Timestamped ACK Frame Format 461 Using this time stamp parameter we can calculate whether the prior 462 blocks transmitted missing deadline or not, and we can also calculate 463 the block completion rate before deadline. 465 4.3. Redundancy Packet 467 We use a F Flags in DTP Packet to distinguish which DTP packets is 468 Redundancy-protected or not. Figure 5 shows the Redundancy Packet 469 Format. If the flag is set, the Redundancy Payload INFO field is 470 appended to the header. The Redundancy Payload INFO is an opaque 471 field for the protocol. It is used by the Redundancy Scheme to 472 identify the redundancy-protected data and communicate information 473 about the encoding and decoding procedures to the receiver-side 474 Redundancy Scheme. 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+ 479 |F| Flags(7) | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 ... 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Redundancy Payload INFO (i)(if F set) ... 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Payload (i) ... 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 5: Redundancy Packet Format 490 o F: A flag indicating whether this DTP packets is FEC-protected or 491 not. 493 o FEC Payload INFO: A variable-length integer containing the 494 information of Redundancy Group ID and packet index in this 495 Redundancy Group. 497 o Payload: The payload of the Redundancy Packet, containing DTP 498 Payload or Redundancy Data. 500 5. DTP Use Cases 502 5.1. Block Based Real Time Application 504 DTP can provide deliver-before-deadline service for Block Based Real 505 Time Applications. Applications like real-time media and online 506 multiplayer gaming have deadline requirements for their data 507 transimission. These application also tend to generate and process 508 the data in block fashion, for example, video/audio encoder produces 509 the encoded streams as a series of block (I,B,P frame or GOP). And 510 these real-time applications usually have multiple blocks (As shown 511 in Figure 1) to be transferred simultaneously. DTP can optimize the 512 data transmission of these applications by scheduling which block to 513 be sent first. And Redundancy Module of DTP can reduce 514 retransmission delay. 516 5.2. API of DTP 518 DTP extends the send socket API to let application attach metadata 519 along with the data block, and the API of DTP is structured as 520 follows: 522 5.2.1. Data Transmission Functions 524 Send 526 Format: SEND(connection id, buffer address, byte count, block id, 527 block deadline, block priority) -> byte count 529 The return value of SEND is the continuous bytes count which is 530 successfully written. If the transport layer buffer is limited or 531 the flow control limit of the block is reached, application needs 532 to call SEND again. 534 Mandatory attributes: 536 * connection id - local connection name of an indicated 537 connection. 539 * buffer address - the location where the block to be transmitted 540 is stored. 542 * byte count - the size of the block data in number of bytes. 544 * block id - the identity of the block. 546 * block deadline - deadline of the block. 548 * block priority - priority of the block. 550 Update 552 Format: UPDATE(connection id, block id, block deadline, block 553 priority) -> result 555 The UPDATE function is used to update the metadata of the block. 556 The return value of UPDATE function indicates the success of the 557 action. It will return success code if succeeds, and error code 558 if fails. 560 Mandatory attributes: 562 * connection id - local connection name of an indicated 563 connection. 565 * block id - the identity of the block. 567 * block deadline - new deadline of the block. 569 * block priority - new priority of the block. 571 Retreat 573 Format: RETREAT(connection id, block id) -> result 575 The RETREAT function is used to cancel the block. The return 576 value of RETREAT function indicates the success of the action. It 577 will return success code if succeeds, and error code if fails. 579 Mandatory attributes: 581 * connection id - local connection name of an indicated 582 connection. 584 * block id - the identity of the block. 586 Receive 588 Format: RECV(connection id, buffer address, byte count, [,block 589 id]) -> byte count, fin flag, [,block id] 591 The RECV function shall read the first block in-queue into the 592 buffer specified, if there is one available. The return value of 593 RECV is the number of continuous bytes which is successfully read, 594 and fin flag to indicate the ending of the block. If the block is 595 cancelled, the RECV function will return error code 596 BLOCK_CANCELLED. It will also returns the block id on which it 597 receives if application does not specify it. 599 If the block size specified in the RECV function is smaller than 600 the size of the receiving block, then the block will be partial 601 copied(indicated by the fin flag). Next time RECV function is 602 called, the remaining block will be copied, and the id will be the 603 same. This fragmentation will give extra burden to applications. 604 To avoid the fragmentation, sender and receiver can negotiate a 605 max block size when handshaking. 607 Mandatory attributes: 609 * connection id - local connection name of an indicated 610 connection. 612 * buffer address - the location where the block received is 613 stored. 615 * byte count - the size of the block data in number of bytes. 617 Optional attributes: 619 * block id - to indicate which block to receive the data on. 621 5.2.2. Feedback Functions 623 Status 625 Format: STATS(connection id, block id) -> byte count 627 The STATS function is used to query the deadline delivery result. 628 The application uses STATS to query the bytes delivered before the 629 deadline to receiver of each block. The information can be used 630 to adjust the block sending rate of each priority. For example, 631 if the application finds that the lowest priority block always get 632 dropped due to the limited bandwidth, the application can stop 633 generating the block to save the computation power. Combined the 634 status of each priority, the application can also get the overall 635 network capacity to facilitate the rate adaptation algorithm. 637 Mandatory attributes: 639 * connection id - local connection name of an indicated 640 connection. 642 * block id - the identity of the block. 644 Block Completion Time (BCT) 646 Format: QUERY_BCT(connection id, block id) -> block completion 647 time 649 After receiving the block, application can query the block 650 completion time using QUERY_BCT. This can also facilitate the 651 rate or deadline adaptation of application. For example, if the 652 base RTT of the network is bigger than deadline, then all blocks 653 will miss the deadline. In this case, application may choose to 654 relax its deadline. 656 Mandatory attributes: 658 * connection id - local connection name of an indicated 659 connection. 661 * block id - the identity of the block. 663 All these functions mentioned above are running in asynchronous mode. 664 An application can use various event driven framework to call those 665 functions. 667 6. IANA Considerations 669 This document has no actions for IANA. 671 7. Security Considerations 673 See the security considerations in [QUIC] and [QUIC-TLS]; the block- 674 based data of DTP shares the same security properties as the data 675 transmitted within a QUIC connection 677 8. Normative References 679 [arXiv:1809.04822] 680 Michel, F., Coninck, Q., and O. Bonaventure, "Adding 681 Forward Erasure Correction to QUIC", September 2018. 683 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 684 and Secure Transport", draft-ietf-quic-transport-20 (work 685 in progress), April 2019. 687 [QUIC-TLS] 688 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 689 draft-ietf-quic-tls-20 (work in progress), April 2019. 691 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 692 DOI 10.17487/RFC0768, August 1980, 693 . 695 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 696 RFC 793, DOI 10.17487/RFC0793, September 1981, 697 . 699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 700 Requirement Levels", BCP 14, RFC 2119, 701 DOI 10.17487/RFC2119, March 1997, 702 . 704 Authors' Addresses 706 Yong Cui 707 Tsinghua University 708 30 Shuangqing Rd 709 Beijing 710 China 712 Email: cuiyong@tsinghua.edu.cn 714 Zhiwen Liu 715 Tsinghua University 716 30 Shuangqing Rd 717 Beijing 718 China 720 Email: liu-zw16@mails.tsinghua.edu.cn 722 Hang Shi 723 Tsinghua University 724 30 Shuangqing Rd 725 Beijing 726 China 728 Email: shi-h15@mails.tsinghua.edu.cn 730 Jie Zhang 731 Tsinghua University 732 30 Shuangqing Rd 733 Beijing 734 China 736 Email: zhangjie19@mails.tsinghua.edu.cn 738 Kai Zheng 739 Huawei 741 Email: kai.zheng@huawei.com 742 Wei Wang 743 Huawei 745 Email: wangwei375@huawei.com