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, 04 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
- questions on draft-ietf-quic-recovery Yoshifumi Nishida
- Re: questions on draft-ietf-quic-recovery Ian Swett
- Re: questions on draft-ietf-quic-recovery Yoshifumi Nishida
- Re: questions on draft-ietf-quic-recovery Ian Swett
- Re: questions on draft-ietf-quic-recovery Yoshifumi Nishida