Return-Path: X-Original-To: quic-issues@ietfa.amsl.com Delivered-To: quic-issues@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898013A13E3 for ; Fri, 1 May 2020 08:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.919 X-Spam-Level: X-Spam-Status: No, score=-3.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com 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 smo-_dXkA4_i for ; Fri, 1 May 2020 08:02:05 -0700 (PDT) Received: from out-17.smtp.github.com (out-17.smtp.github.com [192.30.252.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B3D3A136E for ; Fri, 1 May 2020 08:02:04 -0700 (PDT) Received: from github-lowworker-39b4a70.va3-iad.github.net (github-lowworker-39b4a70.va3-iad.github.net [10.48.16.66]) by smtp.github.com (Postfix) with ESMTP id 075636E124D for ; Fri, 1 May 2020 08:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1588345324; bh=tG2oAC4OjKtoBf1AfLwdjjBnTkiLDYDTxFyOlBZwYNU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=f50ASzYeHZOtYhZ70D2NBLop+NpQLgCvRuCw5C0pqPXoe+AY06LH36BHk3RnmYzG6 stLs+KTdJ2IRkSs1Q9ZEkU3gOeZDk5mtW/ZX9aap13DKsMK8XTl27ewsj2BloXkAyr /XYgHPjARi9nyi5J/vYrd5UstYAaWEBRuB+M1IyY= Date: Fri, 01 May 2020 08:02:03 -0700 From: Gorry Fairhurst Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Changing the Default QUIC ACK Policy (#3529) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5eac39ebec32f_a823f890cecd96487966"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: gorryfair X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org Archived-At: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 15:02:18 -0000 ----==_mimepart_5eac39ebec32f_a823f890cecd96487966 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable These results/article on computational efficiency are really =0D interesting. Please see below.=0D =0D On 01/05/2020 05:40, Kazuho Oku wrote:=0D > Hi, Gorry=0D >=0D > Thank you for sharing your experiments. I'm delighted to see results =0D= > showing that use of ack10 gives us comparable throughput to ack2.=0D >=0D > Recently, I have been looking into how ack-frequency affects the =0D > computational efficiency of the server [1]. Using the (almost) same =0D= > setup, I have today run a benchmark comparing three ACK strategies: =0D= > ack2, ack10, ack 1/8cwnd.=0D >=0D > ack2: 334Mbps=0D > ack10: 414Mbps=0D > ack 1/8cwnd: 487Mbps=0D >=0D > As can be seen, ack10 is better than ack2, but lags behind ack1/8cwnd. = =0D > That's because there are still frequent ACKs. They take considerable =0D= > amount of CPU cycles.=0D >=0D This is useful, we see here there's a clear benefit here in using a =0D larger ACK Ratio also in terms of server load.=C2=A0 We can see already t= he =0D benefit at 1:10 and GSO helps as expected.=0D > If we want to see QUIC being as lightweight as TLS over TCP, it is =0D > critically important to reduce ACK frequency as much as possible. This = =0D > is because the cost of processing ACK in QUIC is much more expensive =0D= > than TCP, due QUIC being a userspace transport.=0D >=0D We think that this is also really true. QUIC ACKs are also larger than =0D= TCP ACKs (see https://erg.abdn.ac.uk/users/gorry/ietf/QUIC/).=0D > Based on this, if we are to change what we have in the base drafts, =0D= > I'd much prefer adopting what we have in the proposed delayed ack =0D > extension [2], rather than just changing the default ack policy from =0D= > ack2 to ack10. By adopting what we have in the delayed ack extension, =0D= > we can expect better performance, and the endpoints would have the =0D > freedom to change the behavior when the default ack policy is deemed =0D= > insufficient (regardless of the default being ack2 or ack10).=0D >=0D > [1] =0D > https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficie= ncy=0D > [2] https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00=0D >=0D I don't think the two approaches conflict.=0D =0D The difference between the two approaches is that the small change to =0D= the base specification to use an ACK Ratio 1:10 ensures the default =0D return path is at least as good as TCP for common traffic (even with =0D common TCP ACK Thinning). Without this change, the end user could =0D experience significant differences in performance between TCP and =0D between different QUIC versions over asymmetric paths.=E2=80=A8=0D =0D Whereas to me, the transport parameter extension looks like an exciting =0D= way to enable many more things, but there are also many ways this could =0D= usefully evolve based on CC, offload, pacing etec and I think this will =0D= take much more to work-out what is needed, safe and best ... then to =0D reach consensus. We still also need to specify a default ACK Ratio in =0D= this case as well.=0D =0D Best wishes,=0D =0D Gorry=E2=80=A8=0D > 2020=E5=B9=B44=E6=9C=8828=E6=97=A5(=E7=81=AB) 20:37 Gorry Fairhurst >:=0D > >=0D > > On 27/04/2020 17:19, Lars Eggert wrote:=0D > >=0D > > Folks who care about a change here need to prioritize progressing =0D= > this issue. We're close to being able to last-call the specs, and =0D > would like this resolved in time..=0D > >=0D > > =E2=80=94=0D > > You are receiving this because you authored the thread.=0D > > Reply to this email directly, view it on GitHub, or unsubscribe.=0D > >=0D > > We=E2=80=99ve completed a round of updated analysis of the proposed c= hange =0D > to the QUIC spec, using quicly (changing to a 1:10 policy), and =0D > chromium (which currently does 1:10 by default). Our hope is that this = =0D > change to the spec, =C2=A0to actually make standard end-to-end QUIC wor= k =0D > better than TCP over asymmetric paths!=0D > >=0D > > This is a short slide deck about the performance of the proposed chan= ge:=0D > > https://erg.abdn.ac.uk/users/gorry/ietf/QUIC/QUIC-ack10-24-april-00.p= df=0D > >=0D > > There have been a number of other change made by the QUIC ID editors = =0D > relating to ACK processing, so we wanted to be sure these results were = =0D > up to date. (These results do not consider additional ACKs after =0D > re-ordering - reflecting the latest text removing that.)=0D > >=0D > > We also really hope this will motivate a change the practice of =0D > forcing of QUIC fallback to TCP (with PEP/Thining) over highly =0D > asymmetric paths. People may also be interested in work for L4S to =0D > evaluate the impact of ACK Thining for TCP-Prague.=0D > >=0D > > Please do provide feedback, or any questions on this - as Lars =0D > notes, we think the time is running out for considering new changes, =0D= > even relatively simple ones like this.=0D > >=0D > > Gorry=0D > >=0D > > P.S. First email: =0D > https://mailarchive.ietf.org/arch/msg/quic/NZBbuY88v0lrVspQE2A5br83asA/= =0D >=0D >=0D >=0D > --=0D > Kazuho Oku=0D =0D =0D -- =0D You are receiving this because you are subscribed to this thread.=0D Reply to this email directly or view it on GitHub:=0D https://github.com/quicwg/base-drafts/issues/3529#issuecomment-622423228= ----==_mimepart_5eac39ebec32f_a823f890cecd96487966 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=0D These results/article on computational efficiency are really
=0D interesting. Please see below.
=0D
=0D On 01/05/2020 05:40, Kazuho Oku wrote:
=0D > Hi, Gorry
=0D >
=0D > Thank you for sharing your experiments. I'm delighted to see res= ults
=0D > showing that use of ack10 gives us comparable throughput to ack2.=0D >
=0D > Recently, I have been looking into how ack-frequency affects the =0D > computational efficiency of the server [1]. Using the (almost) same =
=0D > setup, I have today run a benchmark comparing three ACK strategies: =
=0D > ack2, ack10, ack 1/8cwnd.
=0D >
=0D > ack2: 334Mbps
=0D > ack10: 414Mbps
=0D > ack 1/8cwnd: 487Mbps
=0D >
=0D > As can be seen, ack10 is better than ack2, but lags behind ack1/8cwn= d.
=0D > That's because there are still frequent ACKs. They take consider= able
=0D > amount of CPU cycles.
=0D >
=0D This is useful, we see here there's a clear benefit here in using a <= br>=0D larger ACK Ratio also in terms of server load.=C2=A0 We can see already t= he
=0D benefit at 1:10 and GSO helps as expected.
=0D > If we want to see QUIC being as lightweight as TLS over TCP, it is <= br>=0D > critically important to reduce ACK frequency as much as possible. Th= is
=0D > is because the cost of processing ACK in QUIC is much more expensive=
=0D > than TCP, due QUIC being a userspace transport.
=0D >
=0D We think that this is also really true. QUIC ACKs are also larger than =0D TCP ACKs (see https://erg.abdn.ac.uk/users/gorry/ietf/QUIC/).
=0D > Based on this, if we are to change what we have in the base drafts, =
=0D > I'd much prefer adopting what we have in the proposed delayed ac= k
=0D > extension [2], rather than just changing the default ack policy from=
=0D > ack2 to ack10. By adopting what we have in the delayed ack extension= ,
=0D > we can expect better performance, and the endpoints would have the <= br>=0D > freedom to change the behavior when the default ack policy is deemed=
=0D > insufficient (regardless of the default being ack2 or ack10).
=0D= >
=0D > [1]
=0D > https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-effi= ciency
=0D > [2] https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00=0D >
=0D I don't think the two approaches conflict.
=0D
=0D The difference between the two approaches is that the small change to =0D the base specification to use an ACK Ratio 1:10 ensures the default
=0D= return path is at least as good as TCP for common traffic (even with
= =0D common TCP ACK Thinning). Without this change, the end user could
=0D= experience significant differences in performance between TCP and
=0D= between different QUIC versions over asymmetric paths.=E2=80=A8
=0D
=0D Whereas to me, the transport parameter extension looks like an exciting <= br>=0D way to enable many more things, but there are also many ways this could <= br>=0D usefully evolve based on CC, offload, pacing etec and I think this will <= br>=0D take much more to work-out what is needed, safe and best ... then to
= =0D reach consensus. We still also need to specify a default ACK Ratio in =0D this case as well.
=0D
=0D Best wishes,
=0D
=0D Gorry=E2=80=A8
=0D > 2020=E5=B9=B44=E6=9C=8828=E6=97=A5(=E7=81=AB) 20:37 Gorry Fairhurst = <gorry@erg.abdn.ac.uk
=0D > <mailto:gorry@erg.abdn.ac.uk>>:
=0D > >
=0D > > On 27/04/2020 17:19, Lars Eggert wrote:
=0D > >
=0D > > Folks who care about a change here need to prioritize progressi= ng
=0D > this issue. We're close to being able to last-call the specs, an= d
=0D > would like this resolved in time..
=0D > >
=0D > > =E2=80=94
=0D > > You are receiving this because you authored the thread.
=0D > > Reply to this email directly, view it on GitHub, or unsubscribe= .
=0D > >
=0D > > We=E2=80=99ve completed a round of updated analysis of the prop= osed change
=0D > to the QUIC spec, using quicly (changing to a 1:10 policy), and
= =0D > chromium (which currently does 1:10 by default). Our hope is that th= is
=0D > change to the spec, =C2=A0to actually make standard end-to-end QUIC = work
=0D > better than TCP over asymmetric paths!
=0D > >
=0D > > This is a short slide deck about the performance of the propose= d change:
=0D > > https://erg.abdn.ac.uk/users/gorry/ietf/QUIC/QUIC-ack10-24-apri= l-00.pdf
=0D > >
=0D > > There have been a number of other change made by the QUIC ID ed= itors
=0D > relating to ACK processing, so we wanted to be sure these results we= re
=0D > up to date. (These results do not consider additional ACKs after =0D > re-ordering - reflecting the latest text removing that.)
=0D > >
=0D > > We also really hope this will motivate a change the practice of=
=0D > forcing of QUIC fallback to TCP (with PEP/Thining) over highly
=0D= > asymmetric paths. People may also be interested in work for L4S to <= br>=0D > evaluate the impact of ACK Thining for TCP-Prague.
=0D > >
=0D > > Please do provide feedback, or any questions on this - as Lars =
=0D > notes, we think the time is running out for considering new changes,=
=0D > even relatively simple ones like this.
=0D > >
=0D > > Gorry
=0D > >
=0D > > P.S. First email:
=0D > https://mailarchive.ietf.org/arch/msg/quic/NZBbuY88v0lrVspQE2A5br83a= sA/
=0D >
=0D >
=0D >
=0D > --
=0D > Kazuho Oku
=0D =0D =0D

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub,= or unsubscribe.3D""

=0D = ----==_mimepart_5eac39ebec32f_a823f890cecd96487966--