profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/syohex/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Shohei YOSHIDA syohex DeNA Co., Ltd. Tokyo, Japan https://syohex.org Fighting gamer

jrblevin/markdown-mode 649

Emacs Markdown Mode

defunkt/coffee-mode 573

Emacs Major Mode for CoffeeScript

emacs-php/php-mode 529

A powerful and flexible Emacs major mode for editing PHP scripts

kyagi/shell-pop-el 179

shell-pop.el helps you to use shell easily on Emacs. Only one key action to work.

expez/evil-smartparens 120

Evil integration for Smartparens

msgpack/msgpack-perl 48

MessagePack serializer implementation for Perl / msgpack.org[Perl]

mattn/p5-Devel-CheckLib 13

check that a library is available

bergey/org-babel-diagrams 9

embed haskell diagrams in emacs org-mode files

CPFL/velodyne 8

ROS support for Velodyne 3D LIDARs

diasbruno/pastery.el 4

pastery for emacs.

startedaardappel/treesheets

started time in 21 minutes

startedymmt2005/grpc-tutorial

started time in 34 minutes

Pull request review commenth2o/quicly

picocc

+/*+ * Copyright (c) 2019-2021 Fastly, Janardhan Iyengar, Kazuho Oku+ *+ * Permission is hereby granted, free of charge, to any person obtaining a copy+ * of this software and associated documentation files (the "Software"), to+ * deal in the Software without restriction, including without limitation the+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or+ * sell copies of the Software, and to permit persons to whom the Software is+ * furnished to do so, subject to the following conditions:+ *+ * The above copyright notice and this permission notice shall be included in+ * all copies or substantial portions of the Software.+ *+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS+ * IN THE SOFTWARE.+ */+#include "quicly/cc.h"+#include "quicly.h"++#define QUICLY_MIN_CWND 2+#define QUICLY_PICO_BETA 0.5+#define QUICLY_PICO_RECOVERY_PERIOD 1000 /* in milliseconds */

Works for me!

kazuho

comment created time in an hour

pull request commenth2o/quicly

picocc

@kazuho -- My point was about convergence to a fair share, since the multiplicative increase will cause the system to move slower towards equal shares.

kazuho

comment created time in an hour

startedbazelbuild/intellij

started time in an hour

pull request commenth2o/quicly

picocc

@janaiyengar

Theoretically, this will have slightly reduced convergence speed than Reno

I'm not sure if I follow this. The effect of additive component is going to be equivalent for both Reno and Pico. Therefore, I presume that the convergence speed of the two algorithms will be the same. Though Pico will experience more loss events when the BDP is high (which is an intentional behavior).

kazuho

comment created time in 2 hours

pull request commenth2o/quicly

[reno] better handling of high-BDP connections

Closing in favor of #470.

kazuho

comment created time in 2 hours

PR closed h2o/quicly

[reno] better handling of high-BDP connections

Adds a flag called highbdp_mode that changes the increase ratio.

The increase ratio of ordinary Reno is 1 mtu per round-trip (i.e. CWND being acked).

When in high-BDP mode, the CC uses exponential increase during congestion avoidance phase, where the increase rate is calculated so that it would reach the send rate at which the loss was observed every ~1 second. This is roughly equal to what Cubic does.

+41 -13

3 comments

2 changed files

kazuho

pr closed time in 2 hours

fork tkf/Dagger.jl

A framework for out-of-core and parallel execution

fork in 2 hours

PR opened h2o/h2o

[http3] add support for picocc congestion controller

See https://github.com/h2o/quicly/pull/470.

+213 -57

0 comment

14 changed files

pr created time in 3 hours

Pull request review commenth2o/quicly

picocc

+/*+ * Copyright (c) 2019-2021 Fastly, Janardhan Iyengar, Kazuho Oku+ *+ * Permission is hereby granted, free of charge, to any person obtaining a copy+ * of this software and associated documentation files (the "Software"), to+ * deal in the Software without restriction, including without limitation the+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or+ * sell copies of the Software, and to permit persons to whom the Software is+ * furnished to do so, subject to the following conditions:+ *+ * The above copyright notice and this permission notice shall be included in+ * all copies or substantial portions of the Software.+ *+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS+ * IN THE SOFTWARE.+ */+#include "quicly/cc.h"+#include "quicly.h"++#define QUICLY_MIN_CWND 2+#define QUICLY_PICO_BETA 0.5+#define QUICLY_PICO_RECOVERY_PERIOD 1000 /* in milliseconds */

This PR has been merged, but please let me know if you have suggestions regarding the name.

kazuho

comment created time in 3 hours

push eventh2o/quicly

Kazuho Oku

commit sha 51edf39ea8e393f819e447d5e83cb56169ebf91b

implement pico cc

view details

Kazuho Oku

commit sha 24dba9127f57bbcd163115d1890afa9be35064cc

Update include/quicly/cc.h Co-authored-by: Jana Iyengar <jiyengar@fastly.com>

view details

Kazuho Oku

commit sha 94317b0a10d717d0ca7ffd7e068402556c985768

Update lib/cc-pico.c Co-authored-by: Jana Iyengar <jiyengar@fastly.com>

view details

Kazuho Oku

commit sha 37bf413ad399d4509fb22dcf405e41ca033ea49c

code reuse, changing pico's BETA to 0.7

view details

Kazuho Oku

commit sha e9ac46534929824cee6389829d938787045a63d2

rename, use Hz

view details

Kazuho Oku

commit sha 2002981732b9b12354e576b90746c37baca5d513

[refactor] expose `impl` as `type`, adding `name` as a field

view details

Kazuho Oku

commit sha b4c33691c223d97d6389ba3ea082bd80fef1b051

add API to switch between CCs

view details

Kazuho Oku

commit sha 9cb3a030bf3af14f84f1dcf8ffd62a72163cb55d

add special handling for cc.name now that it is a string

view details

Kazuho Oku

commit sha 029e34a4c9d91b0ba445e3792f53f6de2a4e4008

include reference to init in type so that we do not need to hard code the names at the user-side

view details

Kazuho Oku

commit sha 9481a38bc7325524cce92d9d202b2f17ce8dfd0f

retain list of CC types so that apps can iterate and find

view details

Kazuho Oku

commit sha ec297791fc678e2d16a45e05a429842291029cd0

Merge pull request #470 from h2o/kazuho/picocc picocc

view details

push time in 3 hours

PR merged h2o/quicly

picocc

This is a tiny CC which is a conceptual purification of #469.

The algorithm is dead simple: increase per every byte being acked is calculated as 1mtu/cwnd + (is_slow_start ? 1 : (1/beta -1) * rtt). Beta is 0.5.

The only mode that we have is the is_slow_start flag, that only changes the multiplicative coefficient. There's nothing like choosing a better value from two.

Regarding the formula, 1mtu/cwnd is the increase ratio of traditional Reno during congestion avoidance phase. (1/beta - 1) * rtt is the exponential increase used during the congestion avoidance phase in the highbdp reno variant; for details, see #469.

The key observations regarding this CC are:

  • For convergence, use an increase policy that has an additive component and an multiplicative component, as suggested by the Chiu & Jain paper in 1989 (see proposition 1 on p.9).
  • During congestion avoidance, when the recovery period of traditional Reno (that is proportional to flow_rate * RTT<sup>2</sup>) is small, we do slightly better than traditional Reno, because in addition to doing the addtive increase, the "base" being the multiplicative part shoots up by 2x within 0.4~1 second.
  • During congestion avoidance, when the recovery period of traditional Reno is large, we do much better than traditional Reno, because thanks to the multiplicative part, we shoot up to the original rate within 1 second, provided that the RTT is below 1 second.
  • During slow start, the CWND is increased by 2x + 1 per round-trip, as the paper says that we should have an additive component. Though we can remove it if we want to do what Reno / Cubic has done.

Compared to our Reno that uses beta 0.7, this CC is superior in sense that:

  • When the recovery period is small, it is not as aggressive as our Reno. The problem with our Reno is that it is overaggressive compared to ordinary Reno or linux's implementation of Cubic that essentially falls back to Reno when the recovery period is small (am I correct, @janaiyenger?).
  • When the recovery period is big, it is more agressive than our Reno due to the same reasons as high-bdp Reno (#469).

Compared to high-bdp Reno (#469), this CC is superior in sense that:

  • It follows the recommendation by the paper.
  • There's no logic like picking the more aggressive increase value among the two during congestion avoidance.
+196 -45

1 comment

10 changed files

kazuho

pr closed time in 3 hours

pull request commenth2o/quicly

picocc

Some micro experiments:

The logs below shows CWND reduction events from one short distance connection (Tokyo-Tokyo) and a long distance connection (Tokyo-Johannesburg), transferring data at full speed for 15 seconds. Each log line shows the time, CWND post-reduction, and RTT.

Because the buffer size of the bottleneck is as large as ~190ms, all of the runs showed transfer speed of ~35Mbps.

However, as is evident from these traces, Reno does not observe losses once it finishes ramping down to the correct value post slow start. These are proofs that Reno is fragile to random losses / shallow buffers in high BDP connections.

Compared to that, Pico is periodically testing the peek, between every 1 to 2 seconds in both short and long distance connections.

short reno:
**** 1624580413867 - quicly_cc_reno_on_lost:71 cwnd=1506445,rtt=187
**** 1624580414203 - quicly_cc_reno_on_lost:71 cwnd=1054511,rtt=201
**** 1624580414519 - quicly_cc_reno_on_lost:71 cwnd=739053,rtt=203

short pico:
**** 1624580623553 - quicly_cc_reno_on_lost:71 cwnd=1498560,rtt=180
**** 1624580623891 - quicly_cc_reno_on_lost:71 cwnd=1083936,rtt=204
**** 1624580624198 - quicly_cc_reno_on_lost:71 cwnd=784739,rtt=210
**** 1624580625451 - quicly_cc_reno_on_lost:71 cwnd=816325,rtt=205
**** 1624580626575 - quicly_cc_reno_on_lost:71 cwnd=808867,rtt=205
**** 1624580627761 - quicly_cc_reno_on_lost:71 cwnd=813502,rtt=207
**** 1624580628853 - quicly_cc_reno_on_lost:71 cwnd=797931,rtt=203
**** 1624580630073 - quicly_cc_reno_on_lost:71 cwnd=812119,rtt=205
**** 1624580631213 - quicly_cc_reno_on_lost:71 cwnd=806819,rtt=206
**** 1624580632329 - quicly_cc_reno_on_lost:71 cwnd=795941,rtt=199
**** 1624580633519 - quicly_cc_reno_on_lost:71 cwnd=806246,rtt=196
**** 1624580634678 - quicly_cc_reno_on_lost:71 cwnd=812564,rtt=202
**** 1624580635800 - quicly_cc_reno_on_lost:71 cwnd=800858,rtt=200
**** 1624580636982 - quicly_cc_reno_on_lost:71 cwnd=809688,rtt=204
**** 1624580638107 - quicly_cc_reno_on_lost:71 cwnd=799741,rtt=203
**** 1624580639320 - quicly_cc_reno_on_lost:71 cwnd=813386,rtt=205

long reno:
**** 1624581697081 - quicly_cc_reno_on_lost:71 cwnd=3722233,rtt=566
**** 1624581698163 - quicly_cc_reno_on_lost:71 cwnd=2605563,rtt=567

long pico:
**** 1624581518444 - quicly_cc_reno_on_lost:71 cwnd=3396288,rtt=561
**** 1624581519520 - quicly_cc_reno_on_lost:71 cwnd=2699961,rtt=553
**** 1624581520942 - quicly_cc_reno_on_lost:71 cwnd=2509108,rtt=576
**** 1624581522545 - quicly_cc_reno_on_lost:71 cwnd=2492887,rtt=578
**** 1624581524167 - quicly_cc_reno_on_lost:71 cwnd=2480636,rtt=578
**** 1624581525813 - quicly_cc_reno_on_lost:71 cwnd=2491773,rtt=573
**** 1624581527418 - quicly_cc_reno_on_lost:71 cwnd=2481649,rtt=578
**** 1624581529063 - quicly_cc_reno_on_lost:71 cwnd=2490690,rtt=580
**** 1624581530668 - quicly_cc_reno_on_lost:71 cwnd=2482683,rtt=576
**** 1624581532292 - quicly_cc_reno_on_lost:71 cwnd=2480662,rtt=580
**** 1624581533931 - quicly_cc_reno_on_lost:71 cwnd=2480143,rtt=578
kazuho

comment created time in 3 hours

Pull request review commenth2o/quicly

picocc

+/*+ * Copyright (c) 2019-2021 Fastly, Janardhan Iyengar, Kazuho Oku+ *+ * Permission is hereby granted, free of charge, to any person obtaining a copy+ * of this software and associated documentation files (the "Software"), to+ * deal in the Software without restriction, including without limitation the+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or+ * sell copies of the Software, and to permit persons to whom the Software is+ * furnished to do so, subject to the following conditions:+ *+ * The above copyright notice and this permission notice shall be included in+ * all copies or substantial portions of the Software.+ *+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS+ * IN THE SOFTWARE.+ */+#include "quicly/cc.h"+#include "quicly.h"++#define QUICLY_MIN_CWND 2+#define QUICLY_PICO_BETA 0.5+#define QUICLY_PICO_RECOVERY_PERIOD 1000 /* in milliseconds */

"multiplicative"

kazuho

comment created time in 3 hours

startedymmt2005/grpc-tutorial

started time in 3 hours

release DeNA/unity-meta-check

3.0.0-dev2

released time in 4 hours

create barnchh2o/h2o

branch : kazuho/h3-picocc

created branch time in 4 hours

push eventh2o/quicly

Kazuho Oku

commit sha 9481a38bc7325524cce92d9d202b2f17ce8dfd0f

retain list of CC types so that apps can iterate and find

view details

push time in 7 hours

push eventh2o/quicly

Kazuho Oku

commit sha 743ceb1e550b0e5b858430940261579243abcd31

retain list of CC types so that apps can iterate and find

view details

push time in 7 hours

Pull request review commenth2o/quicly

picocc

+/*+ * Copyright (c) 2019-2021 Fastly, Janardhan Iyengar, Kazuho Oku+ *+ * Permission is hereby granted, free of charge, to any person obtaining a copy+ * of this software and associated documentation files (the "Software"), to+ * deal in the Software without restriction, including without limitation the+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or+ * sell copies of the Software, and to permit persons to whom the Software is+ * furnished to do so, subject to the following conditions:+ *+ * The above copyright notice and this permission notice shall be included in+ * all copies or substantial portions of the Software.+ *+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS+ * IN THE SOFTWARE.+ */+#include "quicly/cc.h"+#include "quicly.h"++#define QUICLY_MIN_CWND 2+#define QUICLY_PICO_BETA 0.5+#define QUICLY_PICO_RECOVERY_PERIOD 1000 /* in milliseconds */

What's MULT stand for?

kazuho

comment created time in 7 hours

push eventh2o/quicly

Kazuho Oku

commit sha 029e34a4c9d91b0ba445e3792f53f6de2a4e4008

include reference to init in type so that we do not need to hard code the names at the user-side

view details

push time in 7 hours

push eventh2o/quicly

Kazuho Oku

commit sha 05a65f02381408042d5d55e50dc5eed1373ed069

include reference to init in type so that we do not need to hard code the names at the user-side

view details

push time in 7 hours

startedavinassh/grpc-errors

started time in 10 hours

PR opened h2o/h2o

[test fix] Single thread 50access-log.t

The test sometimes fails spuriously because curl requests end up being interleaved

    not ok 1

    #   Failed test at t/50access-log.t line 63.
    #
'GET::/query?abc=d::HTTP/1.1::127.0.0.1:41975::default'
    #     doesn't match
'(?^:^GET::/::HTTP/1\.1::127\.0\.0\.1:[0-9]+::default$)'
    not ok 2
    1..2
not ok 5 - ltsv-related
    # Subtest: timings
        # Subtest: http1

    #   Failed test at t/50access-log.t line 63.
    #                   'GET::/::HTTP/1.1::127.0.0.1:41975::default'
    #     doesn't match
'(?^:^GET::/query\?abc=d::HTTP/1\.1::127\.0\.0\.1:[0-9]+::default$)'
    # Looks like you failed 2 tests of 2.
+1 -0

0 comment

1 changed file

pr created time in 12 hours

startedmicrosoft/GDK

started time in 12 hours

fork orisano/jenkins.io

A static site for the Jenkins automation server

https://jenkins.io

fork in 12 hours

push eventh2o/quicly

Kazuho Oku

commit sha 2002981732b9b12354e576b90746c37baca5d513

[refactor] expose `impl` as `type`, adding `name` as a field

view details

Kazuho Oku

commit sha b4c33691c223d97d6389ba3ea082bd80fef1b051

add API to switch between CCs

view details

Kazuho Oku

commit sha 9cb3a030bf3af14f84f1dcf8ffd62a72163cb55d

add special handling for cc.name now that it is a string

view details

push time in 14 hours