[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

QUIC Working Group                                          Jaehwoon Lee
Internet-Draft                                        Dongguk University
Intended status: Informational                              Younghan Kim
Expires: April 7, 2018                               Soongsil University
                                                         October 8, 2017



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


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 April 7, 2018.

Copyright Notice

   Copyright (c) 2017 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 Apr. 7, 2018               [Page 1]


Internet-Draft              Delayed ack frame              Oct. 8, 2017





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..........................................3
   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 don'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 Apr. 7, 2018               [Page 2]


Internet-Draft              Delayed ack frame              Oct. 8, 2017


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                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          RTT 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. Whether to contain the value in the delayed ack frame is for
   further study.


4.  Security Considerations

   TBD


5.  IANA Considerations

   TBD


 Jaehwoon Lee              Expires Apr. 7, 2018               [Page 3]


Internet-Draft              Delayed ack frame              Oct. 8, 2017


6.  References

   [1]  J. Iyengar and M. Thomson, "QUIC: A UDP-based multiplexed and
        secure transport", draft-ietf-quic-transport-04 (work in
        progress), June 13, 2017.

   [2]  J. Iyengar and I. Swett, "QUIC loss detection and congestion
        control", draft-ietf-quic-recovery-04 (work in progress),
        June 13, 2017.

   [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 Apr. 7, 2018               [Page 4]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/