Re: [tcpm] questions on draft-ietf-quic-recovery

Yoshifumi Nishida <> Sun, 04 November 2018 08:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A069127332; Sun, 4 Nov 2018 01:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2OD3nsSbqxJS; Sun, 4 Nov 2018 01:22:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2402B127133; Sun, 4 Nov 2018 01:22:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 2B42127877C; Sun, 4 Nov 2018 17:22:10 +0900 (JST)
Received: by with SMTP id b7-v6so8647285itd.5; Sun, 04 Nov 2018 01:22:10 -0700 (PDT)
X-Gm-Message-State: AGRZ1gKEF4Snvkjci3LwceK8UhyTrtNmPcCu2kDydZ7/bBYK87Jni4T2 ra4l1WsDOq/lU9LAzhksiItCML6kuljvTtGUw4s=
X-Google-Smtp-Source: AJdET5euM1sbnFMB12aukH53ThHfqZmRsImlHMnMyh3yEiJXMLN9pyrOgHPBY9Vqnf8WmI7QOc83idxzx3+MfYFu/rA=
X-Received: by 2002:a05:660c:9c6:: with SMTP id i6mr3393573itl.25.1541319728503; Sun, 04 Nov 2018 01:22:08 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Yoshifumi Nishida <>
Date: Sun, 4 Nov 2018 01:21:57 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
Cc: Yoshifumi Nishida <>,, "" <>,
Content-Type: multipart/alternative; boundary="000000000000e722940579d2764c"
Archived-At: <>
Subject: Re: [tcpm] questions on draft-ietf-quic-recovery
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 04 Nov 2018 08:22:16 -0000

Hi Ian,

On Sat, Nov 3, 2018 at 3:28 PM Ian Swett <> wrote:

> On Thu, Nov 1, 2018 at 7:12 PM Yoshifumi Nishida <>
> wrote:
>> Hi Ian,
>> Thank you so much for the detailed response. Things are getting clearer
>> to me now.
>> I will need to have some time to think about some of them, but I would
>> like to comments on the following points.
>> Also, I am very sorry that I have mostly read -15 version and didn't have
>> enough time to check -16 carefully (so, my question on was wrong) .
>> I will try to re-read -16 before the meeting.
> Not a problem, the drafts are still changing quite rapidly.
>> On Tue, Oct 30, 2018 at 6:34 PM Ian Swett <ianswett=
>>> wrote:
>> >
>> > Thanks for your careful reading, answers inline.
>> > On Mon, Oct 29, 2018 at 1:03 PM Yoshifumi Nishida <
>>> wrote:
>> >> 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?
>> >
>> > Yes, there's an open Issue to clarify this.
>> >
>> > The outstanding PR is quite old, but has some helpful clarifications in
>> it, so I'm intending to migrate the best parts to a new PR.  Suggestions(or
>> PRs) welcome.
>> I don't have explicit suggestions for now, but I guess we will need to
>> think about the following 2 questions.
>> Q1: Should implementations should support both modes or are they allow to
>> support only one of them?
>> Q2: An implementation that supports both modes can activate both logics
>> at the same time or the mode should be used exclusively?
>> I think these questions will lead to another question: How much freedom
>> implementations should have. For example, how much implementations should
>> follow the pseudo codes.
> The existing text says one may use one or the other or both.  I tend to
> think we'll end up with always using both and removing the early retransmit
> special case.  I believe the recent RACK draft removes early retransmit
> entirely, correct?(BTW, it mentions early retransmit, but doesn't
> explicitly say it replaces it from my reading).  If you think that would be
> an improvement, I can file an issue for that and it might be worth
> discussing in tcpm.

The current RACK uses adopted reordering window and it will be ACK-based
when no reordering is observed. I am thinking it might be an interesting
topic to be discussed.

>> 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
>> >> method)
>> >>    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.
>> >
>> >
>> > The timer is taken from Linux, as mentioned at the end of 4.2.2.  It's
>> categorized as ACK based because it is only armed when a packet with a
>> larger packet number than the one being lost has been acknowledged.  One
>> could argue the same issue for time based loss detection, which also needs
>> a timer.
>> >
>> > Instead of 4*SMSS, we specify kReorderingThreshold, since it seemed
>> like the core issue being fixed was that there was no other mechanism for
>> quickly declaring these packets lost, and if one did implement adaptive
>> reordering tolerance, one threshold wouldn't be out of sync with the other.
>> >
>> > The intent is that like RACK, timer based loss detection subsumes early
>> retransmit.  But yes, this text could use some further clarification,
>> including and not limited to items pointed out in #1212.
>> Hmm... but, as you implement the logic in such a way, I think the current
>> early transmit logic in the draft is similar to the TLP logic in the draft.
>> If time_reordering_fraction is 1/8, it seems to me they are mostly
>> identical.
>> (Well, one may say this is a natural thing because early transmit and
>> TLP is aiming similar goal)
> I tried to clarify the timers used in Early Retransmit and Time-Based loss
> detection in PR#1957 <>.
> Please take a look if you have time.  The text about time-based loss
> detection needs further work, but this is a start along that direction.

OK. I will think about this a bit more.

> I might still overlook something, but it seems to me that the ack-based
>> scheme in QUIC just looks the time-based scheme in QUIC + retransmission
>> scheme with dupack threshold.
>> But, in this case, I am wondering that it may be enough just to have
>> ack-based scheme.
> I'm not sure I understand fully, but I expect that's because the current
> text is unclear.

Or, I overlook something. In any case, I think it is great to have a chance
to discuss specifically loss discovery and CC. Thank you so much!