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

Ian Swett <> Sat, 03 November 2018 22:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C4A8130DC6 for <>; Sat, 3 Nov 2018 15:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3-VO6NceLaaB for <>; Sat, 3 Nov 2018 15:28:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A290130DF5 for <>; Sat, 3 Nov 2018 15:28:17 -0700 (PDT)
Received: by with SMTP id o15-v6so1818738wrv.4 for <>; Sat, 03 Nov 2018 15:28:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I1DWqSZCs+ulrEkue1DkZ9xC1zxjh6y206+kWVG3nTE=; b=gcxLmYPAkujwxQfe+7e8wE1dYQMbim+PGluy2R+dN6lO/HV0nULaPHgk+srEI0N696 akQyNireIqmCnQnW3yNUxdZuWCPyZhkR/MsoljmDBZOTK2SOziulhKmPLi5hLUN+B9QY N2e1fLtbeubB6T7ctmey31kK3f6ABsajJd7Eo3j9BzKYIDDiauf+GL4bzvoR1yHkg33p ekGx7GoeKvs1Cr1f5OgKXw7BWmcy7a5FYQeTyzCenpxGHxq5USmwrDQF/86ZmLMSYDVS za6Aatu43i47W5YD6xd+MGqrIk0yH+HjOj4zsszyYSaM2W9qaesEtXhmomHZSnSyjWb3 /oUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I1DWqSZCs+ulrEkue1DkZ9xC1zxjh6y206+kWVG3nTE=; b=qcqE/3Nl7s/QnP+3E2MtDVatx/9szJv0iTXKKkPzESFtHlJeJ151VLXMmvcT4GFmNf 8e/L2WwKCXswy5CXQPccjD8D41Yx0Y65oXuLO1RvyHt8XcWcJuazxtY16wQxtXNDQW8H 13nFajnqfh/7rBqiqQ/WUrAFrN1+/b4eMTMX+uer1xIh/zUzG9iQ8+LIh2u+/q2quNqR zgtAcTvqP9zRhVjxe5uWe+hAui7ud8bJCLi/bKuitjomQNBGasAo4RST2Nq2GP3JCT19 6Dd6/rE8k7wI12ODDhE5gi0vpfimqGSOS95phLeq2uTOH79oL6ADdfdBtt2RdXzqMVD3 HWzg==
X-Gm-Message-State: AGRZ1gIHFbcw7cW+Ds+keHFBmSKcFhXP3v8vjlD+ayS7df+D+5EoehEu ytPp99l/CLltxHkkH5XLItD2LNMzUXR79V89tL+xow==
X-Google-Smtp-Source: AJdET5cK/xZWhMXewQUi5ptLea/QIUEwO2rRjMjH8I99gW2VJFhIt/u3cJCxnhJQXm4L6EeOGk+Icja4/TXtf26LvbE=
X-Received: by 2002:a5d:6489:: with SMTP id r9-v6mr13079979wru.92.1541284095488; Sat, 03 Nov 2018 15:28:15 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ian Swett <>
Date: Sat, 3 Nov 2018 18:28:03 -0400
Message-ID: <>
Cc: Jana Iyengar <>,, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="000000000000032a910579ca2bb0"
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: Sat, 03 Nov 2018 22:28:27 -0000

On Thu, Nov 1, 2018 at 7:12 PM Yoshifumi Nishida <>

> 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.

> >> 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.

> 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.

> BTW, the original early retransmit in RFC5827 is to reduce dupack
> threshold (kReorderingThreshold in QUIC) when outstanding data is less
> than 4 *SMSS.
> Another condition is to activate only when there's no data to be sent in
> the queue.
> I  am thinking there would be a way to do this type of early retransmit in
> QUIC by tweaking reordering_threshold although I probably don't recommend
> it.
> Thanks,
> --
> Yoshi