Internet DRAFT - draft-jaehwoon-quic-delayed-ack
draft-jaehwoon-quic-delayed-ack
QUIC Working Group Jaehwoon Lee
Internet-Draft Dongguk University
Intended status: Informational Younghan Kim
Expires: December 21, 2018 Soongsil University
June 22, 2018
Delayed acknowledgement transmission time consideration in QUIC
draft-jaehwoon-quic-delayed-ack-01
Abstract
This draft defines a frame type called delayed ack timer. Packet
transmission time and retransmission time-out (RTO) timer setup
value are included in the frame. The sender can send the frame
with the non real-time stream frame within an packet.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 21, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jaehwoon Lee Expires Dec. 21, 2018 [Page 1]
Internet-Draft Delayed ack frame June 22, 2018
Table of Contents
1. Introduction.................................................2
2. Conventions and Terminology..................................3
2.1. Conventions used in this document........................3
2.2. Terminology ............................................3
3. Delayed ack frame............................................3
4. Security Considerations......................................3
5. IANA Considerations..........................................4
6. References....................................................4
Author's Address.................................................4
1. Introduction
QUIC is a multiplexed and secure transport protocol that runs on top
of UDP and can provide a flexible set of features that allow it to be
a general-purpose transport for multiple applications [1].
In order to provide the secure communication, loss detection and
congestion control is defined for QUIC [2]. There can be either
real-time traffic or non real-time traffic. In case of real-time
traffic, a receiver should transmit an ack frame immediately whenever
it receives a packet sent from a sender. The push bit in TCP is
defined for this purpose. However, the receiver doesn't need to send
an ack frame immediately per every received packet containing non
real-time data stream. The receiver can send an accumulated ack frame
for several packet in order to reduce the number of packet containing
only an ack frame. In this case, if an ack frame transmitted by the
receiver arrives at the sender lately, then RTO timer is expired in
the sender which incurs the packet re-transmission. One way to avoid
retransmission of packet is to use the static timer for delaying
sending ack frame such as TCP. The other way is to use the timer to
dynamically adjust based on the transmission time and the
retransmission time-out timer value sent by the sender. In this case,
if we can know the one-way latency from the receiver to the sender,
the it is possible to precisely set the timer value [3].
In this draft, we define the frame called delayed ack containing the
packet transmission time and RTO time-out value sent by the sender.
Jaehwoon Lee Expires Dec. 21, 2018 [Page 2]
Internet-Draft Delayed ack frame June 22, 2018
2. Conventions and Terminology
2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
2.2 Terminology
TBD
3. Delayed ack frame
The frame type for delayed ack defined in this draft is as follows.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| packet transmission time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTO timer value (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The frame can be included in the packet that contains non real-time
stream with stream id not equal to 0. The receiver can transmit
its ack frame by using the conventional way when the received packet
does not contain the delayed ack frame. The packet transmission time
and its RTO time-out timer value is included in the delayed ack
frame. The type for the frame is TBD. How to setup the value for the
delayed ack timer is for further study. When the receiver only
receives data stream from the sender, then it cannot know the latency
between the receiver and the sender. If the receiver can know the
latency, then the receiver can precisely adjust the delayed ack timer
value. In order to determine the latency between the receiver and the
sender, receiver transmits the timestamp frame including
(1) frame transmission time that is included in the delayed ack,
(2) frame receive time and (3) frame transmit time that is similar to
the ICMP timestamp request and reply packet. Then, the sender can
know the round trip time (RTT) and can send the value to receiver.
4. Security Considerations
TBD
Jaehwoon Lee Expires Dec. 21, 2018 [Page 3]
Internet-Draft Delayed ack frame June 22, 2018
5. IANA Considerations
TBD
6. References
[1] J. Iyengar and M. Thomson, "QUIC: A UDP-based multiplexed and
secure transport", draft-ietf-quic-transport-12 (work in
progress), May 22, 2018.
[2] J. Iyengar and I. Swett, "QUIC loss detection and congestion
control", draft-ietf-quic-recovery-12 (work in progress),
May 22, 2018.
[3] H. Chan, A. Wei, F. Song and H. Zhang, "One way latency
consideration for Multipath in QUIC", draft-chan-quic-owl-01
(work in progress), Mar. 13, 2017.
[4] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Jaehwoon Lee
Dongguk University
26, 3-ga Pil-dong, Chung-gu
Seoul 100-715, KOREA
Email: jaehwoon@dongguk.edu
Younghan Kim
Soongsil University
369, Sangdo-ro, Dongjak-gu,
Seoul 156-743, Korea
Email: younghak@ssu.ac.kr
Jaehwoon Lee Expires Dec. 21, 2018 [Page 4]
