Re: questions on draft-ietf-quic-recovery

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Sun, 04 November 2018 08:22 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A069127332; Sun, 4 Nov 2018 01:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OD3nsSbqxJS; Sun, 4 Nov 2018 01:22:13 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2402B127133; Sun, 4 Nov 2018 01:22:12 -0700 (PDT)
Received: from mail-it1-f177.google.com (mail-it1-f177.google.com [209.85.166.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2B42127877C; Sun, 4 Nov 2018 17:22:10 +0900 (JST)
Received: by mail-it1-f177.google.com 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: <CAO249yeMcawY6zZE-64QFO+L6NZhFLnvjXw9dnjn0qsqtKW9kw@mail.gmail.com> <CAKcm_gP-CrgUYEU4Vjdeo2sjpsZvebE-NLXGAL97ckntVwvhOQ@mail.gmail.com> <CAO249yfiG6JF6-NxJpXQ2wQOanc4-gGir+SQBYJyBPWqBqYChw@mail.gmail.com> <CAKcm_gNuxQeT9MzRw5fMCEXO_Z_DHVi3qoAs_B+S3QCS68EoWw@mail.gmail.com>
In-Reply-To: <CAKcm_gNuxQeT9MzRw5fMCEXO_Z_DHVi3qoAs_B+S3QCS68EoWw@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Sun, 4 Nov 2018 01:21:57 -0700
X-Gmail-Original-Message-ID: <CAO249yf_DtEcnHtpS_ux6SwKir494+m+Cc5x0qvdGJzRSC_H6w@mail.gmail.com>
Message-ID: <CAO249yf_DtEcnHtpS_ux6SwKir494+m+Cc5x0qvdGJzRSC_H6w@mail.gmail.com>
Subject: Re: questions on draft-ietf-quic-recovery
To: ianswett@google.com
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, jri.ietf@gmail.com, "tcpm@ietf.org" <tcpm@ietf.org>, quic@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e722940579d2764c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/DQCoYofmwr4Gzx8jOWeXcOx8JmE>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=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 <ianswett@google.com>; wrote:

>
>
> On Thu, Nov 1, 2018 at 7:12 PM Yoshifumi Nishida <nishida@sfc.wide.ad.jp>;
> 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 4.5.7.3 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=
>> 40google.com@dmarc.ietf.org>; wrote:
>> >
>> > Thanks for your careful reading, answers inline.
>> > On Mon, Oct 29, 2018 at 1:03 PM Yoshifumi Nishida <
>> nishida@sfc.wide.ad.jp>; 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.
>> https://github.com/quicwg/base-drafts/issues/1212
>> >
>> > 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 <https://github.com/quicwg/base-drafts/pull/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!
--
Yoshi