questions on draft-ietf-quic-recovery

Yoshifumi Nishida <> Mon, 29 October 2018 17:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6421813101F; Mon, 29 Oct 2018 10:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t734ml4oYQrr; Mon, 29 Oct 2018 10:02:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 725B5131011; Mon, 29 Oct 2018 10:02:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 265D7278576; Tue, 30 Oct 2018 02:02:30 +0900 (JST)
Received: by with SMTP id q5so2814594otl.13; Mon, 29 Oct 2018 10:02:30 -0700 (PDT)
X-Gm-Message-State: AGRZ1gJ5cQ73fX2Qk/cEfSiAiTA26YDwwUI+o15oUmxoFB0TlopWX3rj udA77W2kO8H3vCNk4Le70T8eQAnKYpi8ORZH1kg=
X-Google-Smtp-Source: AJdET5cfPzSHL2LhxraGNxr+KRuTeK0Y8B1qSV1PEP3yhprcQY1XGr8k7Fn/gAEMb2PmtDtq7LTtmpA4W+Y2V4oNmNY=
X-Received: by 2002:a9d:2084:: with SMTP id x4mr8497711ota.111.1540832547884; Mon, 29 Oct 2018 10:02:27 -0700 (PDT)
MIME-Version: 1.0
From: Yoshifumi Nishida <>
Date: Mon, 29 Oct 2018 10:02:15 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
Subject: questions on draft-ietf-quic-recovery
To:, "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Oct 2018 17:02:35 -0000


At Bangkok, TCPM WG will have a session to discuss loss recovery and
congestion control mechanism in QUIC and TCP. (11/6 Tuesday
I really appreciate Ian and Jana for the efforts.

I might overlook something as I couldn't follow up all discussion in
QUIC, but I am thinking that it might be good if we could get some
comments on the following questions.
I have listed several questions on the value of some parameters, but
it doesn't mean I disagree with these values. I just would like to
check where these values came from.
Hope this will be useful in some ways.

Section 4:
   QUIC supports both ack and timer for loss detection.
   But, it's not very clear whether an implementation can choose one
of them or it should implement both and can use both at the same time.
Can it be clarified?

Section 4.1.1:
   For RTT sampling, implementations will need to maintain the
transmission time for each sending packets even if they support only
ack-based method.
   But, this requirement might be hard for tiny devices. Wouldn't it
limit the applicability of QUIC?

   "the largest newly acked packet" might be confusing. packet that
acks the largest packet number?

Section 4.2.1:
   TCP RACK's reo_wnd is aiming to be 1/4 RTT. Why QUIC uses 1/8 RTT?

Section 4.2.2:
   The early retransmit logic in QUIC seems to be different from TCP's one.
   It doesn't look ack-based as it relies on timer. (I don't say this
is bad, but it's a bit strange to categorize it as an ack-based
   TCP's early retransmit will be triggered only when the amount of
outstanding data is less than 4*SMSS, but this draft doesn't mention
about the condition. Is there any reason for it?
   when timer-based loss detection is used, it this logic still
available? or it won't be used with timer-based loss detection? We
might need clarifications here.

Section 4.3.2:
   TCP RACK's PTO is aiming to be 2 * SRTT. Why QUIC uses 1.5 * SRTT?

Section 4.3.3:
   RFC5681 uses 1 SMSS as the size of loss window, while QUIC uses 2.
I understand the motivation to reduce the possibility of consecutive
RTO events. But, this may means when TCP and QUIC connections are
under heavy congestion, QUIC connections will recover more quickly
than TCP connections. We might want to think how much QUIC and TCP
should be fair.

   BTW, it might not be necessarily, but QUIC does not need the upper
bound for RTO?

Section 4.4:
   why the default value of max_ack_delay is 25ms?

   Sorry.. what is 1/4 RTT timer for early retransmit?

Section 5.8.1:
   Why the recommended value is 1200 bytes?