Delayed acknowledgement transmission time consideration in QUIC
draft-jaehwoon-quic-delayed-ack-01

Document Type Active Internet-Draft (individual)
Last updated 2018-06-21
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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",
Show full document text