idnits 2.17.1 draft-jaehwoon-quic-delayed-ack-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (June 22, 2018) is 2134 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-12 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-12 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 QUIC Working Group Jaehwoon Lee 2 Internet-Draft Dongguk University 3 Intended status: Informational Younghan Kim 4 Expires: December 21, 2018 Soongsil University 5 June 22, 2018 7 Delayed acknowledgement transmission time consideration in QUIC 8 draft-jaehwoon-quic-delayed-ack-01 10 Abstract 12 This draft defines a frame type called delayed ack timer. Packet 13 transmission time and retransmission time-out (RTO) timer setup 14 value are included in the frame. The sender can send the frame 15 with the non real-time stream frame within an packet. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 21, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction.................................................2 52 2. Conventions and Terminology..................................3 53 2.1. Conventions used in this document........................3 54 2.2. Terminology ............................................3 55 3. Delayed ack frame............................................3 56 4. Security Considerations......................................3 57 5. IANA Considerations..........................................4 58 6. References....................................................4 59 Author's Address.................................................4 61 1. Introduction 63 QUIC is a multiplexed and secure transport protocol that runs on top 64 of UDP and can provide a flexible set of features that allow it to be 65 a general-purpose transport for multiple applications [1]. 66 In order to provide the secure communication, loss detection and 67 congestion control is defined for QUIC [2]. There can be either 68 real-time traffic or non real-time traffic. In case of real-time 69 traffic, a receiver should transmit an ack frame immediately whenever 70 it receives a packet sent from a sender. The push bit in TCP is 71 defined for this purpose. However, the receiver doesn't need to send 72 an ack frame immediately per every received packet containing non 73 real-time data stream. The receiver can send an accumulated ack frame 74 for several packet in order to reduce the number of packet containing 75 only an ack frame. In this case, if an ack frame transmitted by the 76 receiver arrives at the sender lately, then RTO timer is expired in 77 the sender which incurs the packet re-transmission. One way to avoid 78 retransmission of packet is to use the static timer for delaying 79 sending ack frame such as TCP. The other way is to use the timer to 80 dynamically adjust based on the transmission time and the 81 retransmission time-out timer value sent by the sender. In this case, 82 if we can know the one-way latency from the receiver to the sender, 83 the it is possible to precisely set the timer value [3]. 85 In this draft, we define the frame called delayed ack containing the 86 packet transmission time and RTO time-out value sent by the sender. 88 2. Conventions and Terminology 90 2.1. Conventions 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [4]. 96 2.2 Terminology 98 TBD 100 3. Delayed ack frame 102 The frame type for delayed ack defined in this draft is as follows. 104 0 1 2 3 105 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 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | packet transmission time | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | RTO timer value (16) | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 The frame can be included in the packet that contains non real-time 113 stream with stream id not equal to 0. The receiver can transmit 114 its ack frame by using the conventional way when the received packet 115 does not contain the delayed ack frame. The packet transmission time 116 and its RTO time-out timer value is included in the delayed ack 117 frame. The type for the frame is TBD. How to setup the value for the 118 delayed ack timer is for further study. When the receiver only 119 receives data stream from the sender, then it cannot know the latency 120 between the receiver and the sender. If the receiver can know the 121 latency, then the receiver can precisely adjust the delayed ack timer 122 value. In order to determine the latency between the receiver and the 123 sender, receiver transmits the timestamp frame including 124 (1) frame transmission time that is included in the delayed ack, 125 (2) frame receive time and (3) frame transmit time that is similar to 126 the ICMP timestamp request and reply packet. Then, the sender can 127 know the round trip time (RTT) and can send the value to receiver. 129 4. Security Considerations 131 TBD 133 5. IANA Considerations 135 TBD 137 6. References 139 [1] J. Iyengar and M. Thomson, "QUIC: A UDP-based multiplexed and 140 secure transport", draft-ietf-quic-transport-12 (work in 141 progress), May 22, 2018. 143 [2] J. Iyengar and I. Swett, "QUIC loss detection and congestion 144 control", draft-ietf-quic-recovery-12 (work in progress), 145 May 22, 2018. 147 [3] H. Chan, A. Wei, F. Song and H. Zhang, "One way latency 148 consideration for Multipath in QUIC", draft-chan-quic-owl-01 149 (work in progress), Mar. 13, 2017. 151 [4] Bradner, S., "Key words for use in RFCs to Indicate 152 Requirement Levels", BCP 14, RFC 2119, March 1997. 154 Author's Address 156 Jaehwoon Lee 157 Dongguk University 158 26, 3-ga Pil-dong, Chung-gu 159 Seoul 100-715, KOREA 160 Email: jaehwoon@dongguk.edu 162 Younghan Kim 163 Soongsil University 164 369, Sangdo-ro, Dongjak-gu, 165 Seoul 156-743, Korea 166 Email: younghak@ssu.ac.kr